zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: disconnected events and session expiration
Date Sun, 13 Sep 2015 01:19:56 GMT
I used to advise that people treat Disconnected the same as session loss as it’s safer. But,
you can also set a timer when Disconnected is received and when your session timeout elapses
you can then consider session loss (note, use the negotiated value from the ZK handle). FYI
- version 3.0.0 of Apache Curator will have an option to choose this alternate method.


On September 12, 2015 at 4:47:46 PM, Simon (cocoa@gmx.ch) wrote:


I am trying to get a better understanding of Zookeeper and how it should be used. Let’s
talk about the lock recipe (http://zookeeper.apache.org/doc/r3.4.6/recipes.html#sc_recipes_Locks).

- X aquires the lock  
- X does some long running work (longer than the session timeout)  
- X gets partioned away from the quorum while it was doing some work  
- after some time (determined by the timeout passed to ZK) Y will aquire the lock  

In that situation both X and Y are holding the lock (unless X is acting properly). If I understand
the documentation correctly (http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#ch_zkSessions),
X would receive a disconnected event in that situation (but not an expired event unless it
successfully reconnects). So, X should stop doing the work it is doing until it gets reconnected.
How much time does X have to stop the work it is doing? i.e. how long does it take from disconnected
event sent to X to expiration of the ephemeral node used for the lock? Having two clients
inside a critical section protected by a lock would not be a good idea.  

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