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
