[
https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050895#comment-13050895
]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
@benjamin:
- I was under the impression that Mahadev indeed wanted to remove the
LOG_ERROR, but that this patch would be incorporated into 3.4.0 due to slight
change in behavior (some people might rely on the fact that now the chroot is
included)
I added the LOG_ERROR() because chroot should be NULL if it's not used, and
otherwise it should always be included in the server path, but perhaps I
overlooked something here.
- I think NULL should not be returned from sub_string, for the following
reasons:
* in the current code NULL is never returned due to a parenthesis bug on the
enclosing if() statement. strlen(zh->chroot) != 0 will always return 1 and the
strncmp() function will thus compare 1 character of server_path and zh->chroot.
Since they both start with "/" strncmp will equal (0) and thus the if(0) always
fails.
* other cases in sub_string all return the current server_path as default
value
* the documentation (in zookeeper.h) only states that the path is NULL when
the type is ZOO_SESSION_EVENT
* the function documentation for sub_string() says it should return the exact
path if chroot is not included
as far as I am concerned, this patch (or without LOG_ERROR) can just be
incorporated in the next release, but do let mahadev have another look at it :)
> 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
