This is a serious question and a real problem.  It isn't, however, imposed
by ZK.  You have to have a clean strategy for loss of coordination in your
application if you want it to be robust.

I have seen various strategies work reasonably well.  The approach used in
Katta is to build a listener abstraction over the top of ZK.  The central
object maintains a ZK reference and sends change events to a list of
listeners.  This central object can handle the reconnection after expiration
and the dispatch of notifications to listeners.  This is essentially what
you suggest except that the Zk reference is hidden away a bit.  This can be
a bit dangerous if you hide too much of the ZK semantics, but it is not all
that bad if you leave some of those semantics intact.  In particular, you
must not indiscriminantly do retries on failure since that can lead you into
really deep and murky waters very quickly.

On Sun, Jun 7, 2009 at 4:58 PM, Satish Bhatti <> wrote:

> However, if receive
> a Watcher.Event.KeeperState.Expired event, a fresh ZooKeeper client
> instance
> has to be created.  If I were sharing the ZooKeeper instance, then somehow
> my objects would have to be notified that they should switch to using the
> new ZooKeeper instance.  That means somewhere in my app I would need to
> maintain a list of all objects using ZooKeeper.  Is this the recommended
> approach?  Is there some other more elegant way to do this?

Ted Dunning, CTO

Reply via email to