Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of ahfeel@gmail.com designates
 209.85.213.42 as permitted sender)
MIME-Version: 1.0
Sender: ahfeel@gmail.com
In-Reply-To: <CAEBDDF0.E550%jzimmerman@netflix.com>
References: 
 <CAJwFCa2iNY2XWAefx9nf8fgUz1Ap-6cMhAWRFLhcksKEMax_Rw@mail.gmail.com>
	<CAEBDDF0.E550%jzimmerman@netflix.com>
Date: Fri, 25 Nov 2011 15:44:12 +0100
Message-ID: 
 <CAPZMMAuXmOryLeBYjOFSsyzLNh6BmssXQ7U1VQrqanvr5q5UwA@mail.gmail.com>
Subject: Re: Missing session state handling in most Leader Election
 implementations
From: =?ISO-8859-1?Q?J=E9r=E9mie_BORDIER?= <jeremie.bordier@gmail.com>
To: user@zookeeper.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just a quick post to point at that the leader election example that
was posted on the list earlier today is very clean and handle the
disconnected / expired cases.

https://github.com/cyberroadie/zookeeper-leader/

J=E9r=E9mie

On Fri, Nov 18, 2011 at 7:04 PM, Jordan Zimmerman
<jzimmerman@netflix.com> wrote:
> I just did a quickie test. If the cluster goes down you get the Disconnec=
t
> but do not get a session expiration. So, there wouldn't be an opportunity
> to transition from SUSPENDED to LOST (unless the client makes another ZK
> call). So, this brings me back to doing the background sync().
>
> -JZ
>
> On 11/18/11 9:52 AM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
>
>>Is the background sync even necessary? =A0The ZK client itself will
>>re-establish connection if it can.
>>
>>I think that LOST should only be sent on session expiration.
>>
>>On Fri, Nov 18, 2011 at 1:07 AM, Jordan Zimmerman
>><jzimmerman@netflix.com>wrote:
>>
>>> FYI
>>>
>>> Curator now has a staged connection notification mechanism for dealing
>>> with issues like this. When the Curator managed connection receives a
>>> Disconnect, it posts a message to listeners that the connection is
>>> SUSPENDED. If the connection can be re-established (via a background
>>>sync()
>>> using the current retry policy) the listeners receive RECONNECTED
>>>otherwise
>>> they receive LOST. Thus, users of the Curator LeaderSelector can know i=
f
>>> they should pause their leader activity and/or stop leader activity.
>>>
>>> -JZ
>>> ________________________________________
>>> From: Ted Dunning [ted.dunning@gmail.com]
>>> Sent: Monday, November 14, 2011 6:24 PM
>>> To: user@zookeeper.apache.org
>>> Subject: Re: Missing session state handling in most Leader Election
>>> implementations
>>>
>>> On Mon, Nov 14, 2011 at 2:41 PM, Jordan Zimmerman
>>><jzimmerman@netflix.com
>>> >wrote:
>>>
>>> > It turns out that this is tricky to solve. When the server you're
>>> > connected to goes down, you get a
>>>Watcher.Event.KeeperState.Disconnected.
>>> > However, it could be that you are able to reconnect to another server
>>>so
>>> > the disconnected event should be ignored.
>>>
>>>
>>> The event should not be ignored. =A0The master should pause in being a
>>> master, but not unload any major data structures. =A0If it reconnects
>>> instantly, then it should continue as if nothing had happened. =A0You c=
an
>>> also have a time limit for how long you wait before you decide to pause
>>> operation as master. =A0As you increase that time, you increase the
>>> probability of two masters existing at the same time. =A0If the reconne=
ct
>>> happens before the timeout, you don't need to both the master.
>>>
>
>


--=20
J=E9r=E9mie 'ahFeel' BORDIER