zk server: 3.7.2
After #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.
Originally reported by kuradeon, imported from: LeaderLatch isn't able to recover after zk recover/leaderPath missing.
- assignee: tison
- status: Resolved
- priority: Major
- resolution: Fixed
- resolved: 2024-12-21T20:30:16+00:00
- imported: 2025-01-21
zk server: 3.7.2
After #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.
Originally reported by kuradeon, imported from: LeaderLatch isn't able to recover after zk recover/leaderPath missing.