zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexis Midon <alexismi...@gmail.com>
Subject Re: Watchers & error handling
Date Thu, 24 Jun 2010 20:25:44 GMT
Hi guys,

could you confirm that the default watcher is always invoked for none-type
events, even if the action set a different listener?



On Sat, Jun 12, 2010 at 10:07 PM, Alexis Midon <alexismidon@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message