[CURATOR-202] LeaderSelector node is not removed on connection loss if reconnected to the same session

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.7.1
• Fix Version/s: 2.8.0
• Component/s: Framework, Recipes
• Assignee: Jordan Zimmerman
• Reporter: Sergey Serebryanik
• Created: 02/Apr/15 19:53
• Updated: 10/May/23 15:20
• Resolved: 19/Apr/15 18:15

Description

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.

Issue Links

• fixes: CURATOR-205 Repeated InterruptedExceptions during mutex acquire leads to LeaderSelector deadlock