[
https://issues.apache.org/jira/browse/CURATOR-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Rosenberg updated CURATOR-274:
------------------------------------
Description:
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.
was:
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.
> 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 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)
