You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Benjamin Reed (JIRA)" <ji...@apache.org> on 2011/06/17 02:16:47 UTC

[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in zoo_create()

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050822#comment-13050822 ] 

Benjamin Reed commented on ZOOKEEPER-1027:
------------------------------------------

what are we waiting on for this patch? is is simply to remove the LOG_ERROR?

i'm also wondering if we shouldn't still return NULL if there is a suffix error in sub_string. it seems like we should keep returning a NULL.

> chroot not transparent in zoo_create()
> --------------------------------------
>
>                 Key: ZOOKEEPER-1027
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1027
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: c client
>    Affects Versions: 3.3.3
>         Environment: Linux, ZooKeeper 3.3.3, C-client, java 1.6.0_17-b04, hotspot server vm
>            Reporter: Thijs Terlouw
>            Assignee: Thijs Terlouw
>             Fix For: 3.4.0
>
>         Attachments: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
>
>
> 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 behavior? 
> I workaround this issue now by remembering the chroot in
> my wrapper code and after a call to zoo_create() i check if the returned
> path starts with the chroot. If it does, I remove it.
> 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 believe this only affects the create functions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira