Thanks to @Kezhu Wang for the support to fix the issue
En martes, 8 de abril de 2025, 15:10:23 CEST, evaristo.camar...@yahoo.es
<evaristo.camar...@yahoo.es> escribió:
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
> >
> >
> >
>
