To expand on this, when a client is disconnected, it receives a disconnect event.
>From that time until the client is reconnected, the client doesn't know what has happened. The session may have expired or it may have not expired. Keep in mind that clock changes can make reasoning during this time impossible to do with precision. What the client does during this period of ignorance is up to the designer of the application. There are several potential strategies. If the application must have at most one master, then the disconnected client should immediately stop behaving as a master. If the application must have at least one master, then the disconnected client should continue as master. If you have an in between strategy where it is bad but not fatal to have two masters, you can have the disconnected client behave as a master up to the point where it thinks that it likely has been superseded by some other method. Zookeeper cannot decide this issue for you. On Sun, Nov 25, 2012 at 10:49 AM, Camille Fournier <[email protected]>wrote: > Yes if quorum is intact but the client cannot connect to the zookeeper, the > session and the ephemeral nodes will expire. It is up to users of ZK for > locking to correctly assume that a given client is not the lock holder if > its connection to the ZooKeeper is lost. > > C > > On Sun, Nov 25, 2012 at 1:32 PM, Narayanan Arunachalam < > [email protected]> wrote: > > > Hi, > > > > In case the network between ZK cluster and client is partitioned, once > the > > session expires would it remove the ephemeral nodes? If that's the case > how > > is the correctness of the recipes like locks are archived. Because once > the > > ephemeral nodes are removed next client would be granted the lock isn't > it. > > > > Regards, > > Nara >
