The session expired event means that the the server expired the client and
that means the watches and ephemrals will go away for that node.
How are you running your zookeeper quorum? Session expiry event should be
really rare event . If you have a quorum of servers it should rarely happen.
On 2/12/09 11:17 AM, "Tom Nichols" <tmnich...@gmail.com> wrote:
> So if a session expires, my ephemeral nodes and watches have already
> disappeared? I suppose creating a new ZK instance with the old
> session ID would not do me any good in that case. Correct?
> On Thu, Feb 12, 2009 at 2:12 PM, Mahadev Konar <maha...@yahoo-inc.com> wrote:
>> Hi Tom,
>> We prefer to discard the zookeeper instance if a session expires.
>> Maintaining a one to one relationship between a client handle and a session
>> makes it much simpler for users to understand the existence and
>> disappearance of ephemeral nodes and watches created by a zookeeper client.
>> On 2/12/09 10:58 AM, "Tom Nichols" <tmnich...@gmail.com> wrote:
>>> I've come across the situation where a ZK instance will have an
>>> expired connection and therefore all operations fail. Now AFAIK the
>>> only way to recover is to create a new ZK instance with the old
>>> session ID, correct?
>>> Now, my problem is, the ZK instance may be shared -- not between
>>> threads -- but maybe two classes in the same thread synchronize on
>>> different nodes by using different watchers. So it makes sense that
>>> one ZK client instance can handle this. Except that even if I detect
>>> the session expiration by catching the KeeperException, if I want to
>>> "resume" the session, I have to create a new ZK instance and pass it
>>> to any classes who were previously sharing the same instance. Does
>>> this make sense so far?
>>> Anyway, bottom line is, it would be nice if a ZK instance could itself
>>> recover a session rather than discarding that instance and creating a
>>> new one.
>>> Thanks in advance,