I've been unhappy with this for a while. We should add an interruptLeader() method to the LeaderSelector class. That's the right place to do this and it can handle any edge cases.
Please open a Jira for this. ==================== Jordan Zimmerman On Sep 9, 2013, at 10:32 AM, Arie Zilberstein <[email protected]> wrote: > Hi, > > I'm fairly new with Zookeeper and Curator. I want to achieve a simple leader > election process. > But, I ran into trouble implementing the interruption behavior. I could not > find a reliable way to stop the leader (withdraw from leadership). > I think even the schoolbook example that Curator brings is flawed. > In leader.ExampleClient: > > @Override > public void stateChanged(CuratorFramework client, ConnectionState > newState) > { > // you MUST handle connection state changes. This WILL happen in > production code. > > if ( (newState == ConnectionState.LOST) || (newState == > ConnectionState.SUSPENDED) ) > { > if ( ourThread != null ) > { > ourThread.interrupt(); > } > } > } > > So in case of lost leadership, the ourThread thread is interrupted. However, > ourThread is set in the 2nd line of the takeLeadership() method. Until then, > it is null. > > What happens if the connection is lost immediately after it is established, > and ourThread stays null? Won't it be the case that the thread will go on, > thinking that it is the leader, despite it being supposed to withdraw? > > Thanks, > Arie
