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:
> my watches get recreated on the new server but I'm still too aware of
> In fact, shouldn't disconnect be removed entirely? Or is this just advice
> telling the client that something bad might have happened?
> On Tue, Jan 6, 2009 at 7:12 PM, Mahadev Konar <maha...@yahoo-inc.com> wrote:
>> This has been fixed in zookeeper-3.0 release. Are you using a release from
>> 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
>> > 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
>> > 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
Open Source SOA