curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Zimmerman (JIRA)" <>
Subject [jira] [Resolved] (CURATOR-54) No reliable way to cancel leadership in LeaderSelector when connection fails due to edge cases
Date Tue, 10 Sep 2013 23:01:52 GMT


Jordan Zimmerman resolved CURATOR-54.

    Resolution: Fixed

 It was not possible to correctly handle connection state issues with the LeaderSelectorListener.
There was an edge case where if
    the connection was lost before takeLeadership() was called, the thread would not be known
and the existing sample code on
    how to handle stateChanged would not work.
    Introduced CancelLeadershipException to signal to the LeaderSelector instance that it
should cancel the leadership. Also
    added a direct method of canceling leadership.
> No reliable way to cancel leadership in LeaderSelector when connection fails due to edge
> ----------------------------------------------------------------------------------------------
>                 Key: CURATOR-54
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.2.0-incubating
>            Reporter: Jordan Zimmerman
>            Assignee: Jordan Zimmerman
>             Fix For: 2.3.0-incubating
> From a post to user@
> "Hi,
> I'm fairly new with Zookeeper and Curator. I want to achieve a simple leader election
> 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"

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message