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 --
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.
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,
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
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
session.
Right - once the session is expired the id is invalid. You need to
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
idleness is not a problem. the client library sends heartbeats to keep the
session alive. the client library will also handle reconnects automatically if
a server dies.
since session expiration really is a rare catastrophic event. (or at least it
should be.) it is probably easiest to deal with
The next Bay Area Hadoop User Group meeting is scheduled for Wednesday,
February 18th at Yahoo! 2811 Mission College Blvd, Santa Clara, Building
2, Training Rooms 5 6 from 6:00-7:30 pm.
Agenda:
Fair Scheduler for Hadoop - Matei Zaharia
Interfacing with MySQL - Aaron Kimball
Tom, you might try changing the log4j default log level to DEBUG for the
rootlogger and appender if you have not already done so (servers and
clients both). You'll get more information to aid debugging if it does
occur again.
