curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: LeaderSelector edge case - preventing timely leadership withdrawal
Date Mon, 09 Sep 2013 15:46:18 GMT
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 <azilberstein@salesforce.com> 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

Mime
View raw message