[
https://issues.apache.org/jira/browse/CURATOR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900950#comment-17900950
]
Zili Chen commented on CURATOR-724:
-----------------------------------
> If the leaderPath node doesn't exist after zk recovered
If you mean the contender node, getChildren will found our path doesn't exist
and reset.
If you mean the latchPath, how can it be nonexist? Curator has the assumption
that such node should be handled within the framework and we don't delete it.
[1]
[1] https://curator.apache.org/docs/tech-note-07
> 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
> Priority: Major
>
> 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)
