Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper >> mail # user >> Getting confused with the "recipe for lock"


+
Zhao Boran 2013-01-11, 13:46
+
Andrey Stepachev 2013-01-11, 14:48
+
Hulunbier 2013-01-11, 16:10
+
Jordan Zimmerman 2013-01-11, 20:20
+
Hulunbier 2013-01-12, 10:30
+
Ben Bangert 2013-01-12, 17:39
+
Jordan Zimmerman 2013-01-13, 01:31
+
Hulunbier 2013-01-13, 15:05
+
Vitalii Tymchyshyn 2013-01-14, 10:37
+
Hulunbier 2013-01-14, 15:06
+
Vitalii Tymchyshyn 2013-01-14, 15:38
+
Ted Dunning 2013-01-14, 16:05
+
Hulunbier 2013-01-15, 02:28
+
Hulunbier 2013-01-15, 01:52
+
Jordan Zimmerman 2013-01-15, 02:23
+
Hulunbier 2013-01-15, 03:45
+
Benjamin Reed 2013-01-15, 05:27
+
Hulunbier 2013-01-15, 06:32
+
Ted Dunning 2013-01-17, 11:43
+
Hulunbier 2013-01-18, 08:26
+
Benjamin Reed 2013-01-17, 04:28
+
Hulunbier 2013-01-17, 09:05
+
Vitalii Tymchyshyn 2013-01-27, 19:29
Copy link to this message
-
Re: Getting confused with the "recipe for lock"
Thanks Ben,

> Then the ZK server will tear down the connection, the client will definitely notice the other side of the TCP connection going down and should react appropriately.

It takes time for the tcp segments (FIN) to be sent from server to client.

Even no bad things such as high packet loss rate happen, the recipe
itself can not ensure that,  during the above time gap, client2 will
never think itself successfully acquired the lock.

>An alternative implementation that would alleviate this worry (though introduce the risk of dead-locks) would be to not use ephemeral sequential nodes, and just sequential nodes. This means that a lock would *never* be released until the client releases it, which might be more appropriate for you if this lock is governing something so important. Though you will of course need something else to alert you if its possible you're in a dead-lock scenario (client dies without releasing lock).

I do agree with you on this point.
On Sun, Jan 13, 2013 at 9:31 AM, Jordan Zimmerman
<[EMAIL PROTECTED]> wrote:
> On Jan 12, 2013, at 2:30 AM, Hulunbier <[EMAIL PROTECTED]> 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.
>
> -Jordan