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?
Thanks. -Tom 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. > > 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 > >
