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
>>>
>>
>>
>>
|