zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Simpler ZooKeeper event interface....
Date Wed, 07 Jan 2009 17:32:12 GMT
Take a look at the leader election recipe here:

Also a very simple version of leader election is detailed in the preso:

If the leader is disconnected it can't give up leadership - as it's not 
connected to the cluster it can't make changes to the znodes. That's why 
the recipe uses ephemeral nodes, so that if the cluster _expires_ the 
leaders session (doesn't hear from the client w/in the timeout specified 
by that particular client during session establishment, say the network 
btw the leader/cluster fails) the leader znode will be removed, the 
followers notified, and a new leader elected.

If the leader is disconnected for a short period, then reconnected, this 
may be a non issue from an application (your app) perspective, or it may 
be something that is important to the application as a whole, it's up to 
each implementation whether this is important or just ignored.


Hiram Chirino wrote:
> Knowing about a disconnection may be important to some apps.  For
> example if an app uses ZK for leader election, and the leader gets
> disconnected from ZK, he should give up being the leader, since a
> different leader may get elected while he is disconnected from ZK.
> On Tue, Jan 6, 2009 at 11:58 PM, Kevin Burton <burton@spinn3r.com> wrote:
>> 3.0.1.....
>> my watches get recreated on the new server but I'm still too aware of
>> connections.
>> In fact, shouldn't disconnect be removed entirely?  Or is this just advice
>> telling the client that something bad might have happened?
>> Kevin
>> On Tue, Jan 6, 2009 at 7:12 PM, Mahadev Konar <mahadev@yahoo-inc.com> wrote:
>>> http://issues.apache.org/jira/browse/ZOOKEEPER-23
>>> This has been fixed in zookeeper-3.0 release. Are you using a release from
>>> sourceforge?
>>> mahadev
>>> On 1/6/09 4:57 PM, "Kevin Burton" <burton@spinn3r.com> wrote:
>>>> This could be simplified if the semantics for reconnect were simplified.
>>>> Is there any reason why I should know about a disconnect if ZK is just
>>> going
>>>> to reconnect me to another server in 1ms?
>>>> Why not hide *all* of this form the user and have the client re-issue
>>>> watches on reconnect and hold off on throwing exceptions if the server
>>>> returns.
>>>> This would allow the user to just handle three conditions... total
>>> ensemble
>>>> failure, no ACL permission, or no node existing (of vice-versa).
>>>> Kevin
>>>>> If I run an async request, the client should replay these if I'm
>>>>> reconnected to another host.
>>>>> --
>>>> Founder/CEO Spinn3r.com
>>>> Location: San Francisco, CA
>>>> AIM/YIM: sfburtonator
>>>> Skype: burtonator
>>>> Work: http://spinn3r.com
>> --
>> Founder/CEO Spinn3r.com
>> Location: San Francisco, CA
>> AIM/YIM: sfburtonator
>> Skype: burtonator
>> Work: http://spinn3r.com

View raw message