zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Getting confused with the "recipe for lock"
Date Sun, 13 Jan 2013 01:31:52 GMT
On Jan 12, 2013, at 2:30 AM, Hulunbier <hulunbier@gmail.com> wrote:

> Suppose the network link betweens client1 and server is at very low
> quality (high packet loss rate?) but still fully functional.
> Client1 may be happily sending heart-beat-messages to server without
> notice anything; but ZK server could be unable to receive
> heart-beat-messages from client1 for a long period of time , which
> leads ZK server to timeout client1's session, and delete the ephemeral
> node

I believe the heartbeats go both ways. Thus, if the client doesn't hear from the server it
will post a Disconnected event.

> But I still feels that, no matter how well a ZK application behaves,
> if we use ephemeral node in the lock-recipe; we can not guarantee "at
> any snapshot in time no two clients think they hold the same lock",
> which is the fundamental requirement/constraint for a lock.

Assuming the clocks are in sync between all participants… The server and the client that
holds the lock should determine that there is a disconnection at nearly the same time. I imagine
that there is a certain amount of time (a few milliseconds) overlap here. But, the next client
wouldn't get the notification immediately anyway. Further, when the next client gets the notification,
it still needs to execute a getChildren() command, process the results, etc. before it can
determine that it has the lock. That two clients would think they have the lock at the same
time is a vanishingly small possibility. Even if it did happen it would only be for a few
milliseconds at most.

Someone with better understanding of ZK internals can correct me, but this is my understanding.

View raw message