Ephemerals and watches are maintained across disconnect/reconnect btw
the client and server however session expiration (or closing the session
explicitly) will trigger deletion of ephemeral nodes associated with the
Right - once the session is expired the id is invalid. You need to
create a new session (new id).
Btw, the "timeout" value you provide to when constructing the zookeeper
client session directly effects the session expiration - the server uses
this timeout as the session expiration time.
Tom Nichols 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:
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
Thanks in advance,