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 <bur...@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 <maha...@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" <bur...@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




Reply via email to