Regardless of frequency Tom's code still has to handle this situation.
I would suggest that the "two classes" Tom is referring to in his mail,
the ones that use ZK client object, should either be able to
"reinitialize" with a new zk session, or they themselves should be
discarded and new instances created using the new session (not sure what
makes more sense for his archi...)
Regardless of whether we reuse the session object or create a new one I
believe the code using the session needs to "reinitialize" in some way
-- there's been a dramatic break from the cluster.
As I mentioned, you can decrease the likelihood of expiration by
increasing the timeout - but the downside is that you are less sensitive
to clients dying (because their ephemeral nodes don't get deleted till
close/expire and if you are doing something like leader election among
your clients it will take longer for the followers to be notified).
Patrick
Mahadev Konar wrote:
Hi Tom,
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.
mahadev
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?
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
