[
https://issues.apache.org/jira/browse/CURATOR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kuradeon updated CURATOR-724:
-----------------------------
Description:
After [https://github.com/apache/curator/pull/430], the LeaderLatch will call
getChildren() instead of reset() to recover the leader election. But
getChildren() triggers setNode() via callback
client.getChildren().inBackground(callback).forPath(ZKPaths.makePath(latchPath,
null)). If the leaderPath doesn't exist after zk recovered, then the
LeaderLatch node wouldn't never recovered.
There is a temporary solution, adding a ConnectionStateListener before the
LeaderLatch internal ConnectionStateListener, which to create the leaderPath
node manually. Then this issue will be fixed.
was:https://github.com/apache/curator/pull/430
> LeaderLatch isn't able to recover after zk recover/leader path missing.
> -----------------------------------------------------------------------
>
> Key: CURATOR-724
> URL: https://issues.apache.org/jira/browse/CURATOR-724
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 5.5.0, 5.6.0, 5.7.0, 5.7.1
> Reporter: Kuradeon
> Priority: Major
>
> After [https://github.com/apache/curator/pull/430], the LeaderLatch will call
> getChildren() instead of reset() to recover the leader election. But
> getChildren() triggers setNode() via callback
> client.getChildren().inBackground(callback).forPath(ZKPaths.makePath(latchPath,
> null)). If the leaderPath doesn't exist after zk recovered, then the
> LeaderLatch node wouldn't never recovered.
> There is a temporary solution, adding a ConnectionStateListener before the
> LeaderLatch internal ConnectionStateListener, which to create the leaderPath
> node manually. Then this issue will be fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
