Hi guys, could you confirm that the default watcher is always invoked for none-type events, even if the action set a different listener?
thanks, Alexis On Sat, Jun 12, 2010 at 10:07 PM, Alexis Midon <alexismi...@gmail.com>wrote: > Hi all, > > I implemented queues and locks on top of ZooKeeper, and I'm pretty happy so > far. Thanks for the nice work. Tests look good. So good that we can focus on > exception/error handling and I got a couple of questions. > > #1. Regarding the use of the default watcher. A ZooKeeper instance has a > default watcher, most operations can also specify a watcher. When both are > set, does the operation watcher override the default watcher? > or will both watchers be invoked? if so in which order? Does each watcher > receive all the types of event? > I had a look at the code, and my understanding is that the default watcher > will always receive the type-NONE events, even if an "operation" watcher is > set. No guarantee on the order of invocation though. Could you confirm > and/or complete please? > > #2 After a connection loss, the client will eventually reconnect to the ZK > cluster so I guess I can keep using the same client instance. But are there > cases where it is necessary to re-instantiate a ZooKeeper client? As a first > recovery-strategy, is that ok to always recreate a client so that any > ephemeral node previously owned disappear? > The case I struggle with is the following: > Let's say I've acquired a lock (i.e. an ephemeral locknode is created). > Some application logic failed due to a connection loss. At this stage I'd > like to give up/roll back. Here I would typically throw an exception, the > lock being released in a finally. But I can't release the lock since the > connection is down. Later the client eventually reconnects, the session > didn't expire so the locknode still exists. Now no one else can acquire this > lock until my session expires. > > #3. could you describe the recommended actions for each exception code? > > I hope my questions would make some sense to you. Thanks in advance for > your answers, > > Alexis > > > >
