Evaristo created CURATOR-506:
--------------------------------
Summary: PersistentNode sometimes deletes more ZNodes that
expected when closed
Key: CURATOR-506
URL: https://issues.apache.org/jira/browse/CURATOR-506
Project: Apache Curator
Issue Type: Bug
Components: Recipes
Affects Versions: 4.1.0
Reporter: Evaristo
Hi there,
I have an application using PersistentNode with CreateMode.EPHEMERAL that is
reporting in ZK cluster in ZNode '/level1/level2/level3' and I am relying also
in the recipe to create '/level1' and 'level1/level2' ZNodes.
While testing the application I observe that sporidally when the PersistentNode
is closed '/level1/level2' ZNode is deleted. That ZNode is PERSISTENT so I
think only ''/level1/level2' ZNode should be deleted when closed. I was
checking the code and when the PersistentNode is closed tries to delete what it
is is nodePath variable, but the code does not check what is the exact path
that the variable holds, making the behaviour non 100% determistic under
certain conditions.
In my view, the delete operation under close() method should only affect the
basePath declared in the constructor, and in my view the delete should only
apply when the CreateMode was EPHEMERAL.
I think this code could solve the problem
diff --git
a/curator-recipes/src/main/java/org/apache/curator/framework/recipes/nodes/PersistentNode.java
b/curator-recipes/src/main/java/org/apache/curator/framework/recipes/nodes/PersistentNode.java
index 81e8dd9..ad56cb3 100644
---
a/curator-recipes/src/main/java/org/apache/curator/framework/recipes/nodes/PersistentNode.java
+++
b/curator-recipes/src/main/java/org/apache/curator/framework/recipes/nodes/PersistentNode.java
@@ -409,18 +409,15 @@
protected void deleteNode() throws Exception
{
- String localNodePath = nodePath.getAndSet(null);
- if ( localNodePath != null )
- {
+ nodePath.getAndSet(null);
try
{
- client.delete().guaranteed().forPath(localNodePath);
+ client.delete().guaranteed().forPath(basePath);
}
catch ( KeeperException.NoNodeException ignore )
{
// ignore
}
- }
}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
