Thanks to @Kezhu Wang for the support to fix the issue En martes, 1 de abril de 2025, 13:03:50 CEST, evaristo.camar...@yahoo.es <evaristo.camar...@yahoo.es> escribió: Hi there, Thanks for the answer.
I agree that using "PERSISTENT_WITH_TTL" for the container is a good solution. I provided a PR with that change and a test case ISSUE 1258 by chevaris · Pull Request #1260 · apache/curator | | | | | | | | | | | ISSUE 1258 by chevaris · Pull Request #1260 · apache/curator Fix for Issue 1258 Thanks to Kezhu Wang for the suggestion in the solution | | | Regards, ChevaHi, > When this is happening the CONTAINER node is never deleted. One option is to > increase the touchScheduleFactor, BUT still this solution looks not correct > for me. There is a system property "znode.container.maxNeverUsedIntervalMs" to control this. See also ZOOKEEPER-3546[1]. > In my view the recipe should watch the Container Node itself and just when > the node is created, the recipe could trigger TOUCH node creation to minimize > the opportunity window in which the problem happens. First, there is no TOUCH in ZooKeeper. Second, "CONTAINER" node has no relationship with ttl or mtime. I think we could simply use "PERSISTENT_WITH_TTL" for the container node. So, don't rely on server configuration. [1]: https://issues.apache.org/jira/browse/ZOOKEEPER-3546 On Sun, Mar 30, 2025 at 6:10 PM evaristo.camar...@yahoo.es.INVALID <evaristo.camar...@yahoo.es.invalid> wrote: > > Hi there, > I would appreciate if someone could take a look to PersistentTTLNode fails to > remove node · Issue #1258 · apache/curator > > | > | > | > | | | > > | > > | > | > | | > PersistentTTLNode fails to remove node · Issue #1258 · apache/curator > > PersistentTTLNode (Curator 5.8.0 and probably previous versions) has a corner > case that prevents that ZNode is d... > | > > | > > | > > > The ticket contains description of the problem, test to reproduce and > potential fix. > Thanks in advance, > Cheva > > En lunes, 24 de marzo de 2025, 09:54:58 CET, evaristo.camar...@yahoo.es ><evaristo.camar...@yahoo.es> escribió: > > Hi, > Already open a new GitHub issue. I have included a test that shows the > problem and a potential fix. > PersistentTTLNode fails to remove node · Issue #1258 · apache/curator > > | > | > | > | | | > > | > > | > | > | | > PersistentTTLNode fails to remove node · Issue #1258 · apache/curator > > PersistentTTLNode (Curator 5.8.0 and probably previous versions) has a corner > case that prevents that ZNode is d... > | > > | > > | > > > Regards, > Cheva > > En domingo, 23 de marzo de 2025, 00:43:01 CET, tison ><wander4...@gmail.com> escribió: > > Thanks for your reporting. Yes please open an issue at > https://github.com/apache/curator/issues. > > Best, > tison. > > Evaristo José Camarero <evaristojo...@yahoo.es.invalid> 于2025年3月23日周日 04:26写道： > > > > Hi there, > > I have discovered that PersistentTTLNode (Curator 5.8.0 and probably > > previous versions) has a corner case that prevents that ZNode is deleted > > when program running the recipe is stop in certain situations. > > This is the sequence:- Start the recipe with TTL of 30secs -> Container > > Node is created- Stop the program (or the program crashes in production) > > that runs the recipe before Touch TTL node is created. This is NOT > > deterministic and basically a background thread is scheduled to run TTL/2 > > (by default). In worse case scenario de TTL node could take up to 15 secs > > in this example to be created > > When this is happening the CONTAINER node is never deleted. One option is > > to increase the touchScheduleFactor, BUT still this solution looks not > > correct for me. > > > > In my view the recipe should watch the Container Node itself and just when > > the node is created, the recipe could trigger TOUCH node creation to > > minimize the opportunity window in which the problem happens. > > Let me know if I should open an ISSUE > > Regards, > > Cheva > > > > > > >
