zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Unexpected behavior with Session Timeouts in Java Client
Date Fri, 22 Apr 2011 16:03:09 GMT
Well there are real limits about what knowledge you can have in a split
brain and how much coordination there can be.

Having exactly one master in such situation is impossible.  You get to pick
your error scenario, however.  One option is to have one master almost all
the time with a failure mode of having zero acting masters a bit of the
time.  The other option is to have one master almost all the time with a
failure mode that has two masters a bit of the time.  You get to pick which

As Ben stated, the philosophy of ZK is to report facts that can be
demonstrated.  Your application will work pretty well with a timer even
though that could result in momentary double master situations.  Of course,
it can also result in periods of zero master as well since a master cut off
from ZK may well be cut off from the clients who want to be served.

So the API isn't making a promise it can't keep.  It is promising to report
to you as soon as it is certain of things.  And it does.

On Fri, Apr 22, 2011 at 6:51 AM, Scott Fines <scottfines@gmail.com> wrote:

> I guess my objection would be that the API is making a promise that it can
> only deliver part of the time. If the client can't reconnect to ZooKeeper,
> then the client hasn't expired, which is an unusual state to find oneself
> in, and in leader-election systems like mine could result in having two
> practical leaders, while ZooKeeper is insisting that there is only one.
> This
> kind of split-brain scenario seems unavoidable in the absence of
> probabilistic failure checking (like timeouts).
> The FAQ, I've noticed, does make mention of this phenomenon. Perhaps
> something should be indicated there regarding the why and not just the
> mechanics. Otherwise, developers such as myself might find themselves
> unduly
> confused by it :)
> Thanks for all your help,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message