[
https://issues.apache.org/jira/browse/CURATOR-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968292#comment-14968292
]
ASF GitHub Bot commented on CURATOR-274:
----------------------------------------
Github user Randgalt commented on the pull request:
https://github.com/apache/curator/pull/115#issuecomment-150066091
There's already a test for ensuring path in TestPathChildrenCache
> version 2.9.0 incorrectly calls mkdirs to create container nodes, when
> running against zk 3.4.6
> -----------------------------------------------------------------------------------------------
>
> Key: CURATOR-274
> URL: https://issues.apache.org/jira/browse/CURATOR-274
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 2.9.0
> Reporter: Jason Rosenberg
> Assignee: Jordan Zimmerman
> Priority: Blocker
> Fix For: 2.9.1
>
>
> I recently attempted to upgrade to use curator 2.9.0 (we had been using
> 2.7.0). We are using zookeeper 3.4.6.
> We use the PathChildrenCache, to watch nodes, that can be deleted. Our tests
> fail with 2.9.0 because after we delete a node, the PathChildrenCache
> immediately re-creates the parent directories for the deleted node.
> In the logs, we see:
> {code}
> 2015-10-21 04:51:39,642 WARN [path-cache /parent1/parent2/parent3-0]
> utils.ZKPaths - The version of ZooKeeper being used doesn't support Container
> nodes. CreateMode.PERSISTENT will be used instead.
> {code}
> Unfortunately, this results in persistent nodes being created. But since
> container mode is not available in 3.4.6, it should not have attempted to
> create the container nodes in the first place.
> The behavior starts with PathChildrenCache.refresh(), with call sequence
> below, which happens after the node is deleted:
> {code}
> PathChildrenCache.refresh(); ->
> PathChildrenCache.ensurePath(); ->
> PathChildrenCache.client.createContainers(path); ->
> CuratorFrameworkImpl.checkExists().creatingParentContainersIfNeeded().forPath(ZKPaths.makePath(path,
> "foo")); ->
> ...
> ExistsBulderImpl.ZKPaths.mkdirs(client.getZooKeeper(), parent, true,
> client.getAclProvider(), true);
> {code}
> It seems to be rather unexpected behavior to default to creating persistent
> nodes if container nodes aren't available. Instead, if container nodes are
> not available, the behavior should be to do nothing (this is the behavior
> we've been living with 'til now).
> This is a Blocker, because it prevents upgrading, for anyone who might delete
> a node watched by a PathChildrenCache.
> I did not look to see if a similar issue might exist in the other cache
> recipes, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
