You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Thijs Terlouw (JIRA)" <ji...@apache.org> on 2011/03/24 06:08:05 UTC
[jira] [Created] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
chroot not transparent in zoo_create()
--------------------------------------
Key: ZOOKEEPER-1027
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1027
Project: ZooKeeper
Issue Type: Bug
Components: server
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
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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055370#comment-13055370 ]
Hadoop QA commented on ZOOKEEPER-1027:
--------------------------------------
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12483913/ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
against trunk revision 1140017.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/354//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/354//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/354//console
This message is automatically generated.
> 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, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017758#comment-13017758 ]
Patrick Hunt commented on ZOOKEEPER-1027:
-----------------------------------------
Thijs, thanks for this - would you mind updating this patch for:
1) get it to patch successfully against trunk (you'll probably need two patch files, one for 3.3 branch and one for trunk)
2) add a C based test based on Andrei's example from python (possible?)
3) add the ZOOKEEPER-995 changes to this patch
> 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.3.3, 3.4.0
>
> Attachments: zookeeper-3.3.3.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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Attachment: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
> 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.3.3, 3.4.0
>
> Attachments: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, zookeeper-3.3.3.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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061156#comment-13061156 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
I see that Hadoop QA didn't agree:
-1 core tests. The patch failed core unit tests.
but there are no failed tests in the test report...
> 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, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063678#comment-13063678 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
It seems the code has been refactored, a large block of code has been moved from the function
zookeeper_process(zhandle_t *zh, int events)
to
process_sync_completion(cptr, sc, ia);
the patch requires access to the zhandle_t pointer though, so you get compilation issues about missing "zh"
The simplest solution is to add a 4th parameter (zhandle_t *zh) to the process_sync_completion() function. It compiles and runs the unit tests correctly after this change, but it's a bit complicated to generate a new patch for me, because I am not sure which version to patch against.
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011145#comment-13011145 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
I can confirm that this patch solves the problem I was seeing. I have tried a lot of things to make the unit tests fail for testChroot() but somehow the unit test always succeeds. Perhaps some compilation options are different or different concurrency? Just guessing, it's very strange that the unit tests don't fail :)
> 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.3.3
>
> Attachments: zookeeper-3.3.3.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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011140#comment-13011140 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
I've tried to make a failing unit test, but strangely enough the unit tests return the correct result (even without my patch). I still have to investigate this further, but I believe the two bugs are correctly solved.
> 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.3.3
>
> Attachments: zookeeper-3.3.3.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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061108#comment-13061108 ]
Hadoop QA commented on ZOOKEEPER-1027:
--------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12485539/ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
against trunk revision 1142377.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
-1 core tests. The patch failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/373//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/373//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/373//console
This message is automatically generated.
> 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, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Attachment: (was: zookeeper-3.3.3.patch)
> 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.3.3, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023138#comment-13023138 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
New patch attached which includes unit tests. Should apply cleanly to the trunk, but I have no idea how to trigger the Hadoop QA Bot...
> 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.3.3, 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-1027:
-------------------------------------
Attachment: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
Updated patch to apply on trunk. Thijis can you please take a look and see in case I missed something?
I didnt get a chance to run the tests since I currently dont have access to a linux box.
> 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, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082487#comment-13082487 ]
Mahadev konar commented on ZOOKEEPER-1027:
------------------------------------------
thanks a lot Dheeraj!
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065018#comment-13065018 ]
Hadoop QA commented on ZOOKEEPER-1027:
--------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12486152/ZOOKEEPER-1027-PATCH-TRUNK2.patch
against trunk revision 1146025.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
-1 patch. The patch command could not apply the patch.
Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/392//console
This message is automatically generated.
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032549#comment-13032549 ]
Mahadev konar commented on ZOOKEEPER-1027:
------------------------------------------
one minor nit:
{noformat}
LOG_ERROR(("server path %s does not include chroot path %s",
server_path, zh->chroot));
{noformat}
I think we should comment this out as well, since this wont be an error on a create call. What do you think Thijs?
> 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Andrei Savu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016299#comment-13016299 ]
Andrei Savu commented on ZOOKEEPER-1027:
----------------------------------------
I've seen a similar issue affecting the zookeeper python client (see ZOOKEEPER-995) and I've attached a failing unit test.
> 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.3.3
>
> Attachments: zookeeper-3.3.3.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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011079#comment-13011079 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
*(1)* fix:
{quote}
// ZOOKEEPER-1027/1 : fix strncmp + do not return NULL
if (strncmp(server_path, zh->chroot, strlen(zh->chroot)) != 0) {
LOG_ERROR(("server path %s does not include chroot path %s",
server_path, zh->chroot));
return (char *) server_path;
}
{quote}
> 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
>
> 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063703#comment-13063703 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
no problem, I will do it later today!
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Attachment: zookeeper-3.3.3.patch
ZOOKEEPER-1027 patch by Thijs Terlouw
> 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.3.3
>
> Attachments: zookeeper-3.3.3.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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065071#comment-13065071 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
previous patch had some issues with directory name, fixed that and added a new patch
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061152#comment-13061152 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
Patch looks fine, i just compared yours and mine. There are some open issues from the discussion of Benjamin and me, if you agree with me, then the patch can be released like this :)
> 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, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011095#comment-13011095 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
The call to sub_string() appears to be needed inside zookeeper_process() near line 2062 in zookeeper.c
I'll submit a full patch later
> 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
>
> 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-1027:
-------------------------------------
Fix Version/s: (was: 3.3.3)
marking it for just 3.4 since 3.3.3 isnt planned yet.
> 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Attachment: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
> 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.3.3, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071035#comment-13071035 ]
Hudson commented on ZOOKEEPER-1027:
-----------------------------------
Integrated in ZooKeeper-trunk #1255 (See [https://builds.apache.org/job/ZooKeeper-trunk/1255/])
ZOOKEEPER-1027. chroot not transparent in zoo_create() (Thijs Terlouw via mahadev)
mahadev : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1150802
Files :
* /zookeeper/trunk/src/c/src/zookeeper.c
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/c/tests/TestClient.cc
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062087#comment-13062087 ]
Hadoop QA commented on ZOOKEEPER-1027:
--------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12485539/ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
against trunk revision 1144087.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
-1 core tests. The patch failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/384//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/384//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/384//console
This message is automatically generated.
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011082#comment-13011082 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
{noformat}
diff -Naur zookeeper-3.3.3/src/c/src/zookeeper.c zookeeper-3.3.3-patched/src/c/src/zookeeper.c
--- zookeeper-3.3.3/src/c/src/zookeeper.c 2011-02-24 07:44:56.000000000 +0800
+++ zookeeper-3.3.3-patched/src/c/src/zookeeper.c 2011-03-25 11:11:23.000000000 +0800
@@ -837,10 +837,11 @@
char *ret_str;
if (zh->chroot == NULL)
return (char *) server_path;
- if (strncmp(server_path, zh->chroot, strlen(zh->chroot) != 0)) {
+ //ZOOKEEPER-1027/1 : do not return NULL and fix strncmp
+ if (strncmp(server_path, zh->chroot, strlen(zh->chroot)) != 0) {
LOG_ERROR(("server path %s does not include chroot path %s",
server_path, zh->chroot));
- return NULL;
+ return (char *) server_path;
}
if (strlen(server_path) == strlen(zh->chroot)) {
//return "/"
{noformat}
> 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
>
> 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Hunt updated ZOOKEEPER-1027:
------------------------------------
Priority: Critical (was: Major)
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018334#comment-13018334 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
Hi Patrick, I will try to create an improved patch next weekend, currently I have no time.
> 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.3.3, 3.4.0
>
> Attachments: zookeeper-3.3.3.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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063680#comment-13063680 ]
Mahadev konar commented on ZOOKEEPER-1027:
------------------------------------------
Thijs,
The version to patch against is trunk. Would you be able to provide a patch in that case?
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023146#comment-13023146 ]
Hadoop QA commented on ZOOKEEPER-1027:
--------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12477090/ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
against trunk revision 1091841.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
-1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/229//testReport/
Findbugs warnings: https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/229//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/229//console
This message is automatically generated.
> 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.3.3, 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Attachment: (was: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch)
> 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.3.3, 3.4.0
>
>
> 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Component/s: (was: server)
c client
> 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
>
> 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010592#comment-13010592 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
I realized that I probably need to test it again using the new 3.3.3 C-client code. I only tested against the 3.3.3 server
> chroot not transparent in zoo_create()
> --------------------------------------
>
> Key: ZOOKEEPER-1027
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1027
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> 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
>
> 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010622#comment-13010622 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
tested with 3.3.3 C-client, same problem
> 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
>
> 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011142#comment-13011142 ]
Hadoop QA commented on ZOOKEEPER-1027:
--------------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12474602/zookeeper-3.3.3.patch
against trunk revision 1082362.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.
-1 patch. The patch command could not apply the patch.
Console output: https://hudson.apache.org/hudson/job/PreCommit-ZOOKEEPER-Build/200//console
This message is automatically generated.
> 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.3.3
>
> Attachments: zookeeper-3.3.3.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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065081#comment-13065081 ]
Hadoop QA commented on ZOOKEEPER-1027:
--------------------------------------
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12486412/ZOOKEEPER-1027-PATCH-TRUNK3.patch
against trunk revision 1146025.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 3 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/395//testReport/
Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/395//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/395//console
This message is automatically generated.
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Dheeraj Agrawal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082483#comment-13082483 ]
Dheeraj Agrawal commented on ZOOKEEPER-1027:
--------------------------------------------
yes, i have created a sub-task for this jira. will be uploading patch in some time.
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032808#comment-13032808 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
I think just for 3.4 is good, because it changes the behavior of the C-client a little bit and that should probably not happen in a small patch release such as 3.3.3
About the LOG_ERROR() message: I didn't look in detail at the code-path for creating, so I didn't consider this case. It's a non-functional change, so removing it is no problem for me :)
> 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011077#comment-13011077 ]
Thijs Terlouw commented on ZOOKEEPER-1027:
------------------------------------------
Two problems afaik:
*(1)* I noticed a sub_string(zh, server_path) function that contains a bug at line 840 in zookeeper.c:
{quote}
if (strncmp(server_path, zh->chroot, strlen(zh->chroot) != 0)) {
{quote}
notice that "!= 0" appears inside the 3rd argument to the strncmp() function! So it executes
{quote}
if(strncmp(server_path, zh->chroot, 1)) {
{quote}
which will always fail if the first character is the same. The next if() also fails (server_path length is not equal to chroot usually). This if() has the potential to cause wrong results btw. Then finally it returns the string with the chroot stripped off. So it will strip off the chroot, but for the wrong reason.
*(2)* the sub_string() function is only called for do_foreach_watcher() function (zk_hashtable.c line 273). It doesn't seem to be called in the zoo_create/zoo_acreate/add_string_completion path. This is the bug that influences this bug report.
> 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
>
> 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032543#comment-13032543 ]
Mahadev konar commented on ZOOKEEPER-1027:
------------------------------------------
+1 the patch looks good to me.
> 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.3.3, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Dheeraj Agrawal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082401#comment-13082401 ]
Dheeraj Agrawal commented on ZOOKEEPER-1027:
--------------------------------------------
Mahadev, this patch breaks windows build.
//ZOOKEEPER-1027
const char* client_path = sub_string(zh, res.path);
Windows doesn't like declaration of variables in middle of the code... The declaration of const char* client_path should be made just after the if condition at line 1898.
1898 if (sc->rc==0) {
1899 const char* client_path;
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Attachment: ZOOKEEPER-1027-PATCH-TRUNK2.patch
ZK-1027 patch updated for trunk. Adds a 4th parameter zhandle_t* to process_sync_completion()
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mahadev konar updated ZOOKEEPER-1027:
-------------------------------------
Attachment: ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch
retrying Thijs patch.
> 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, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Mahadev konar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082470#comment-13082470 ]
Mahadev konar commented on ZOOKEEPER-1027:
------------------------------------------
dheeraj,
Can you please open a new jira and file a patch for it? Please mark it as a blocker for 3.4.0.
thanks
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Updated] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Thijs Terlouw (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thijs Terlouw updated ZOOKEEPER-1027:
-------------------------------------
Attachment: ZOOKEEPER-1027-PATCH-TRUNK3.patch
> 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
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1027-PATCH-TRUNK2.patch, ZOOKEEPER-1027-PATCH-TRUNK3.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, ZOOKEEPER-1027-TRUNK_WITH_TESTS.patch, 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
[jira] [Commented] (ZOOKEEPER-1027) chroot not transparent in
zoo_create()
Posted by "Benjamin Reed (JIRA)" <ji...@apache.org>.
[ 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