You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Jordan Zimmerman (JIRA)" <ji...@apache.org> on 2019/02/07 16:51:00 UTC
[jira] [Closed] (CURATOR-506) PersistentNode sometimes deletes more
ZNodes that expected when closed
[ https://issues.apache.org/jira/browse/CURATOR-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jordan Zimmerman closed CURATOR-506.
------------------------------------
Resolution: Not A Problem
This is as designed. Per [https://cwiki.apache.org/confluence/display/CURATOR/TN7] Curator owns the paths that are given to it. Internally, PersistentNode like all Curator recipes creates parent ZNodes as container nodes (see [https://zookeeper.apache.org/doc/r3.5.4-beta/zookeeperProgrammers.html#Container+Nodes).] Container nodes automatically delete themselves after they are empty for a period of time.
You can get the behavior you want by manually creating the parent paths in advance of starting the PersistenNode. If the ZNodes already exist, PersistenNode will not manage them.
> 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
> Attachments: PN.patch
>
>
> 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)