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.
thanks mahadev 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. > > Thoughts? > > Thanks in advance, > > -Tom
