You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Arie Zilberstein <az...@salesforce.com> on 2013/09/09 17:32:47 UTC
LeaderSelector edge case - preventing timely leadership withdrawal
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
Re: LeaderSelector edge case - preventing timely leadership withdrawal
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <az...@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
Re: LeaderSelector edge case - preventing timely leadership withdrawal
Posted by Arie Zilberstein <az...@salesforce.com>.
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 <az...@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
>
>
>
Re: LeaderSelector edge case - preventing timely leadership withdrawal
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
https://issues.apache.org/jira/browse/CURATOR-54
On Sep 9, 2013, at 10:32 AM, Arie Zilberstein <az...@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