I'll look at this when I get a chance, however, there are a ton of issues
related to ephemerals not getting deleted in the ZK Jira. I suspect this may be
a ZK bug:
I didn’t try adding the extra delete to see if it had an impact, but I created
some docker containers that can be used to replicate the issue if that helps.
Sometimes you have to run a fair number of restarts on the zookeeper containers
to trigger the issue, but I’ve always been able to
A quick thought... I wonder if we need to add a guaranteed delete right here
for the node just in case:
https://github.com/apache/curator/blob/master/curator-framework/src/main/java/org/apache/curator/framework/imps/CreateBuilderImpl.java#L625
> On Jul 30, 2021, at 2:29 PM, H S wrote:
>
> Hi,
Hi,
Thanks for the quick response. On the call to CuratorFramworkFactory.newClient
I am specifying RetryForever as the retry policy if that is the retry policy
you are referring to. I did notice that I was also occasionally seeing that get
interrupted (example stack trace below) but that
Curator has a feature called "protected mode". It adds a UUID to the node name
and when there is connection issue or other connection it tries to find the
node it created (see here:
Hi,
While using the LeaderSelector recipe I noticed what appears to be an issue
where under some circumstances during zookeeper failover or network issues,
orphaned ephemeral nodes are created resulting in no leader election for a
cluster. I have reproduced this issue in versions 5.1.0 and
