Take a look at the leader election recipe here:
http://hadoop.apache.org/zookeeper/docs/r3.0.1/recipes.html#sc_leaderElection
Also a very simple version of leader election is detailed in the preso:
http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperPresentations
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.
Patrick
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
>>
>
>
>
|