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 <cthd2...@gmail.com> 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 DeepDyve
