[jira] [Commented] (CURATOR-724) LeaderLatch isn't able to recover after zk recover/leaderPath missing.

["Zili Chen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CURATOR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906457#comment-17906457 ] 

Zili Chen commented on CURATOR-724:
-----------------------------------

[~kuradeon] You can try out https://github.com/apache/curator/pull/515 and see if it fixes the issue.

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