zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mahadev Konar <maha...@apache.org>
Subject Re: ZooKeeper chroot not transparent in zoo_create()
Date Mon, 28 Mar 2011 06:32:27 GMT
Thanks a lot Thijs. Ill review the patch ASAP.


On Wed, Mar 23, 2011 at 10:08 PM, Thijs Terlouw <thijsterlouw@gmail.com> wrote:
> It took me a while to find that the 3.3.3 release is only available
> via http://zookeeper.apache.org/releases.html and not via
> http://hadoop.apache.org/zookeeper/releases.html anymore, I suggest
> adding a big message on the release page to redirect people.
> Furthermore in the JIRA it still said that 3.3.3 was an "unreleased"
> version.
> I tried the 3.3.3 release and it has the same behavior. I've filed a
> JIRA issue here:
> https://issues.apache.org/jira/browse/ZOOKEEPER-1027
> Thijs
> On Wed, Mar 23, 2011 at 11:25 PM, Mahadev Konar <mahadev@apache.org> wrote:
>> Hi Thijs,
>>  Can you please verify this with 3.3.3 release? If it still exists
>> with 3.3.3 please open a jira.
>> thanks
>> mahadev
>> On Wed, Mar 23, 2011 at 12:12 AM, Thijs Terlouw <thijsterlouw@gmail.com> wrote:
>>> I've recently started to use the chroot functionality (introduced in
>>> 3.2.0) as part of my connect string.It mostly works as expected, but
>>> there is one case that is unexpected: when I create a path with
>>> zoo_create() I can retrieve the created path. This is very useful when
>>> you set the ZOO_SEQUENCE flag. Unfortunately the returned path
>>> includes the chroot as part of the path. This was unexpected to me: I
>>> expected that the chroot would be totally transparent. The
>>> documentation for zoo_create() says:
>>> "path_buffer : Buffer which will be filled with the path of the new
>>> node (this might be different than the supplied path because of the
>>> ZOO_SEQUENCE flag)."
>>> This gave me the impression that this flag is the only reason the
>>> returned path is different from the created path, but apparently it's
>>> not. Is this a bug or intended behaviour. If so, what's the rationale
>>> behind this? It seems I need to manually remove the chroot (I didn't
>>> find a helper function for this either).
>>> My use case is to create a path with a sequence number and then delete
>>> this path later. Unfortunately I cannot delete the path because it has
>>> the chroot prepended to it, and thus it will result in two chroots.
>>> I'm using the C-api and ZooKeeper 3.3.1 in cluster mode.
>>> Thijs Terlouw
> --
> Thijs Terlouw,
> Shenzhen, China
> http://www.startinchina.com

View raw message