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
>
>
>
