[
https://issues.apache.org/jira/browse/CURATOR-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evaristo updated CURATOR-506:
-----------------------------
Description:
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 the code attach in the patch could solve the problem.
Thx in advance,
/evaristo
was:
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
}
- }
}
> 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
> Priority: Major
>
> 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 the code attach in the patch could solve the problem.
>
> Thx in advance,
>
> /evaristo
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)