curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arie Zilberstein <azilberst...@salesforce.com>
Subject Re: LeaderSelector edge case - preventing timely leadership withdrawal
Date Wed, 11 Sep 2013 07:39:53 GMT
Thanks for the quick turnaround.


On Wed, Sep 11, 2013 at 12:55 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> https://issues.apache.org/jira/browse/CURATOR-54
>
> 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