curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rosenberg (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CURATOR-274) version 2.9.0 incorrectly calls mkdirs to create container nodes, when running against zk 3.4.6
Date Wed, 21 Oct 2015 05:17:28 GMT
Jason Rosenberg created CURATOR-274:
---------------------------------------

             Summary: 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
            Priority: Blocker


I recently attempted to upgrade to use curator 2.9.0 (we had been using 2.7.0). We are using
in 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)

Mime
View raw message