[
https://issues.apache.org/jira/browse/CURATOR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17911054#comment-17911054
]
Zili Chen commented on CURATOR-724:
-----------------------------------
Never mind.
[~kuradeon] There is no release containing this fix. So you'd welcome to test
it by building from source against the master branch. I hope we will release
5.8.0 including this patch by the end of Feb.
> LeaderLatch isn't able to recover after zk recover/leaderPath 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
> Assignee: Zili Chen
> Priority: Major
> Fix For: 5.8.0
>
> Attachments: image-2024-11-26-10-17-08-859.png
>
>
> zk server: 3.7.2
> After [https://github.com/apache/curator/pull/430], after the zk was down and
> recovered, the LeaderLatch called 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 node doesn't exist after zk recovered, then the
> LeaderLatch node wouldn't never recreated.
> There is a temporary solution, adding a ConnectionStateListener before the
> LeaderLatch internal ConnectionStateListener, to create the leaderPath node
> manually. Then this issue will be fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
