-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 3.3.3
-
Fix Version/s: 3.4.0
-
Component/s: c client
-
Labels:None
-
Environment:
Linux, ZooKeeper 3.3.3, C-client, java 1.6.0_17-b04, hotspot server vm
-
Hadoop Flags:Reviewed
-
Release Note:Correctly removes the chroot from the returned path in a call to zoo_create()
-
Tags:chroot zookeeper zoo_create
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.
- duplicates
-
ZOOKEEPER-995 C Client exposing chroot information
-
- Resolved
-
- is related to
-
ZOOKEEPER-2282 chroot not stripped from path in asynchronous callbacks
-
- Closed
-