the difference between close and disconnect is that close will actually
try to tell the server to kill the session before disconnecting.
a paranoid lock implementation doesn't need to test it's session. it
should just monitor watch events to look for disconnect and expired
events. if a client is in the disconnected state, it cannot reliably
know if the session is still active, so it should consider the lock in
limbo until it gets either the reconnect event or the expired event.
ben
On 07/06/2010 05:42 PM, Jeremy Davis wrote:
Thanks!
That seems to work, but it is approximately the same as zooKeeper.close() in
that there is no SessionExpired event that comes up through the default
Watcher.
Maybe I'm assuming more from ZK than I should, but should a paranoid lock
implementation periodically test it's session by reading or writing a value?
Regards,
-JD
On Tue, Jul 6, 2010 at 10:32 AM, Mahadev Konar<maha...@yahoo-inc.com>wrote:
Hi Jeremy,
zk.disconnect() is the right way to disconnect from the servers. For
session expiration you just have to make sure that the client stays
disconnected for more than the session expiration interval.
Hope that helps.
Thanks
mahadev
On 7/6/10 9:09 AM, "Jeremy Davis"<jerdavis.cassan...@gmail.com> wrote:
Is there a recommended way of simulating a client session expiration in
unit
tests?
I see a TestableZooKeeper.java, with a pauseCnxn() method that does cause
the connection to timeout/disconnect and reconnect. Is there an easy way
to
push this all the way through to session expiration?
Thanks,
-JD
