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:51:36 GMT
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 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
>>>
>>
>>
>>

Mime
View raw message