zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: locking/leader election and dealing with session loss
Date Wed, 15 Jul 2015 19:16:27 GMT
Even if messages go out of order how does that change the algorithm? Can you explain? The session
is maintained by means of a heartbeat. If a heartbeat is missed then the client goes to Disconnected.
Message ordering in this case shouldn’t matter. Are you saying that message ordering can
cause two clients to think they have the lowest sequence number?

-Jordan



On July 15, 2015 at 2:12:26 PM, Camille Fournier (skamille@gmail.com) wrote:

I don't know what to tell you Jordan, but this is an observable phenomenon and it can happen.
It's relatively unlikely and rare but not impossible. If you're interested in it I'd recommend
reading the chubby paper out of Google, where they discuss it in some detail.

C

On Jul 15, 2015 3:09 PM, "Jordan Zimmerman" <jordan@jordanzimmerman.com> wrote:
He’s talking about multiple writers. Given a reasonable session timeout, even a GC shouldn’t
matter. If the GC causes a heartbeat miss the client will get SysDisconnected.

-Jordan



On July 15, 2015 at 2:05:41 PM, Camille Fournier (skamille@gmail.com) wrote:

If client a does a full gc immediately before sending a message that is
long enough to lose the lock, it will send the message out of order. You
cannot guarantee exclusive access without verification at the locked
resource.

C
On Jul 15, 2015 3:02 PM, "Jordan Zimmerman" <jordan@jordanzimmerman.com>
wrote:

> I don’t see how there’s a chance of multiple writers. Assuming a
> reasonable session timeout:
>
> * Client A gets the lock
> * Client B watches Client A’s lock node
> * Client A gets a network partition
> * Client A will get a SysDisconnected before the session times out
> * Client A must immediately assume it no longer has the lock
> * Client A’s session times out
> * Client A’s ephemeral node is deleted
> * Client B’s watch fires
> * Client B takes the lock
> * Client A reconnects and gets SESSION_EXPIRED
>
> Where’s the problem? This is how everyone uses ZooKeeper. There is 0
> chance of multiple writers in this scenario.
>
>
>
> On July 15, 2015 at 1:56:37 PM, Vikas Mehta (vikasmehta@gmail.com) wrote:
>
> Camille, I don't have a central message store/processor that can guarantee
> single writer (if I had one, it would reduce (still useful in reducing lock
> contention, etc) the need/value of using zookeeper) and hence I am trying
> to
> minimize the chances of multiple writers (more or less trying to guarantee
> this) while maximizing availability (not trying to solve CAP theorem), by
> solving some specific issues that affect availability.
>
>
>
> --
> View this message in context:
> http://zookeeper-user.578899.n2.nabble.com/locking-leader-election-and-dealing-with-session-loss-tp7581277p7581284.html
> Sent from the zookeeper-user mailing list archive at Nabble.com.
>

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