In the case of an active leader, L continues to send commands
(whatever) to the followers. However a new leader L' has since been
elected and is also sending commands to the followers. In this case
it seems like either a) L should not send commands if it's not
sync'd to the ensemble (and
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.
Is
Kevin Burton wrote:
3) it's possible for your code to get notified of a change, but never
process the change. This might happen if:
a) a node changed watch fires
b) your client code runs an async getData
c) you are disconnected from the server
Also, this seems very confusing...
If I run
Hi Vinod,
I think what Ben meant was this--
The client will never know of a session expiration until and unless its
connected to one of the servers. So the leader cannot demote itself since
its connected to one of the servers. It might have lost its session (which
all the others except itself
Mahadev Konar wrote:
Hi Vinod,
I think what Ben meant was this--
The client will never know of a session expiration until and unless its
connected to one of the servers. So the leader cannot demote itself since
its connected to one of the servers. It might have lost its session (which
all the
To say that it will never return is not correct. The client will be
notified of connectionloss in the callback, however the client will
not know if the operation was successful (from point of view of the
server) or not.
Patrick
Kevin Burton wrote:
On Wed, Jan 7, 2009 at 11:12 AM, Mahadev
I guess then I don't follow the leader election recipe. Is the
following scenario possible in the leader election recipe:
1) Leader L is partitioned from the ensemble.
2) ZK servers expire its session.
3) Some other follower F now becomes a leader.
4) L and F form a split brain?
I had
Kevin Burton wrote:
Here's a good reason for each client to know it's session status
(connected/disconnected/expired). Depending on the application, if L does
not have a connected session to the ensemble it may need to be careful how
it acts.
connected/disconnected events are given out in
, January 07, 2009 3:36 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Simpler ZooKeeper event interface
Here's a good reason for each client to know it's session status
(connected/disconnected/expired). Depending on the application, if L does
not have a connected session to the ensemble
