[
https://issues.apache.org/jira/browse/CURATOR-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14393414#comment-14393414
]
Sergey Serebryanik commented on CURATOR-202:
--------------------------------------------
Yes, I'm using the recommended approach with LeaderSelectorListenerAdapter.
Please see my test
https://github.com/serebrserg/curator/blob/CURATOR-202/curator-recipes/src/test/java/org/apache/curator/framework/recipes/leader/TestLeaderSelectorConnectionLoss.java
When watcherClient creates KILL_CONNECTION_PATH node, the connection for the
client used by leaderSelector1 is closed and is being rejected for some time,
but less then session timeout.
I also have a proposal for fix in the following commit
https://github.com/serebrserg/curator/commit/f2fdb22a27303c3dba4b05641c13128370a588e3
> LeaderSelector node is not removed on connection loss if reconnected to the
> same session
> ----------------------------------------------------------------------------------------
>
> Key: CURATOR-202
> URL: https://issues.apache.org/jira/browse/CURATOR-202
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 2.7.1
> Reporter: Sergey Serebryanik
> Priority: Minor
>
> Leader selection fails when connection is lost but restored before session
> timed out.
> TC:
> * the client looses connection to the zookeeper server
> * the client looses leadership
> * the client reconnects to the zookeeper server using the same session
> * the leader node wasn't deleted because the connection was not available on
> deleteOurPath() call, and because the client had reconnected to the same
> session, so the ephemeral node wasn't deleted by zookeeper
> * the client creates the new node
> * no one is the leader because the old leader node stays forever.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
