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 ho
Vinod Johnson wrote:
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 spli
esday, 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 h
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 the
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 wrongl
>
>
> 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 the current AP
Vinod Johnson wrote:
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 se
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
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 o
On Wed, Jan 7, 2009 at 11:12 AM, Mahadev Konar wrote:
> You are right Pat. Replaying an async operation would involve a lot of
> state
> management for clients across servers and would involve a lot more work in
> determining which operation succeeded and the one which needs to be re run
> and the
>
> My assumption is the following - if I'm connected to multiple ZK servers,
> then assuming the leader election recipe given in the docs, the leader needs
> to only demote itself if its session expires. Of course, doing the same on
> disconnect does not violate safety, it just seems too pessimist
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 wou
You are right Pat. Replaying an async operation would involve a lot of state
management for clients across servers and would involve a lot more work in
determining which operation succeeded and the one which needs to be re run
and the semantics of zookeeper client calls would be much harder to
guar
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 an
Benjamin Reed wrote:
You don't demote yourself on disconnect. (Everyone else may still believe you are the
leader.) Check out the "Things to Remember about Watches" section in the
programmer's guide.
When you are disconnected from ZK you don't know what is happening, so you have
to act conser
Btw, not sure if you've looked at this but your code is similar to one
of the examples in the docs:
http://hadoop.apache.org/zookeeper/docs/r3.0.1/javaExample.html
Notice that the listener is ignoring anything other than session expiration.
Patrick
Patrick Hunt wrote:
Take a look at the lead
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 ca
servatively. Your session may or may not have expired. You will not
know for sure until you reconnect to ZK.
ben
From: thomas.john...@sun.com [thomas.john...@sun.com]
Sent: Wednesday, January 07, 2009 8:24 AM
To: zookeeper-user@hadoop.apache.org
Subject: Re
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 th
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,
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 wrote:
> http:
Does javadoc help? :)
Mahadev
On 1/6/09 4:10 PM, "Kevin Burton" wrote:
>>
>>
>> zk.getData( event.getPath(), true, this, null );
>>
>>>
>>>
> Also, why not rename this getDataAsync I can't tell the difference just
> by looking at the method and the different number of arguments.
>
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" wrote:
> This could be simplified if the semantics for reconnect were simplified.
> Is there any reason why I sh
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
>
> 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 an async req
>
>
> zk.getData( event.getPath(), true, this, null );
>
>>
>>
Also, why not rename this getDataAsync I can't tell the difference just
by looking at the method and the different number of arguments.
Should make things a bit more straight forward.
Kevin
--
Founder/CEO Spinn3r.com
Location:
> 1) you are ignoring the result codes in the callbacks, this could get you
> into trouble (say you do a getData on a node that has been deleted ie
> someone changes then immed. deletes the node)
>
Actually I think I removed that FIXME.
I'll try to fix this now..
Another issue was that the A
I should have been more clear on 3c - in this case you will get notified
in the callback of CONNECTIONLOSS for any pending async requests, but as
you are ignoring rc it may cause problems.
Patrick
Patrick Hunt wrote:
Hi Kevin, a couple of issues I noticed while looking at the pastebin:
1) yo
Hi Kevin, a couple of issues I noticed while looking at the pastebin:
1) you are ignoring the result codes in the callbacks, this could get
you into trouble (say you do a getData on a node that has been deleted
ie someone changes then immed. deletes the node)
2) I'm confused by one of your co
Hey guys.
I think I'm finally in the position to push ZK into production for a while
to test it out.
My biggest feedback (other than the small bugs I found) was that the API
could be a bit simpler.
I codified my thoughts here:
http://pastebin.com/f2ecea8c7
http://pastebin.com/f62a01e9
Basicall
30 matches
Mail list logo
