Just to clarify: reconnecting to another server will maintain the same
session or it will fail with session expires.
Flavio Junqueira wrote:
> James, I'd like to clarify what exactly is the issue you're looking at. If
> you provide a list of ZooKeeper servers, then a client will try to reconnect
> to another ZooKeeper server upon a disconnection. Reconnecting to another
> server does not guarantee maintaining the same session, though. So, are you
> trying to guarantee that the session is still the same upon a reconnection?
> If so, I don't think you can do it by just changing the client, since the
> servers might have expired the old session.
>> -----Original Message-----
>> From: James Strachan [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, July 22, 2008 9:09 PM
>> To: firstname.lastname@example.org
>> Subject: things lock up when the client reconnects?
>> I wonder if anyone else has seen this recently; I've been trying to
>> make the WriteLock implementation survive server restarts (i.e.
>> reconnecting to another ZK server) with some success. See the latest
>> patch here...
>> but I've found I can reliably get things to lock up. See the
>> WriteLockTest.java and change the workAroundClosingLastZNodeFails to
>> false and you should be able to run the test yourself and see things
>> lock up.
>> It seems like things lock up when waiting on a Packet being sent to
>> the transport. Sometimes I get a session timed out exception, so if I
>> see that I try and recreate the cxcn object which is maybe causing the
>> issue; I tried patching the ClientCnxn.SendThread.close() method to do
>> a cleanup() to wake up any blocked threads before closing (its in the
>> patch for ZOOKEEPER-78 which also depends on the patch for
>> ZOOKEEPER-84 BTW); am wondering if anyone has a better idea of dealing
>> with a session timeout?
>> Open Source Integration