I'm not sure specifically what info you 'd like to know but our code was
similar to curator's in high level design for locks and retrys. One
modification we'd like to see is to codify the exception handling cases taken
from the wiki into interfaces instead of as an exception handling exercise for
developers. Having a method that throws one of ~20 exception types all
subclassing a top level exception leads to a lot of:
Try {
zooClient.trySomething();
} catch (KeeperException ke) {
// try to do something smart.
}
The problem is that there are a number of different things you may want to do
but the code/api doesn't make that obvious to the developer. It's only after
reading the wiki that you begin to understand what might happen. If the
client/methods took interfaces to handle each of the error cases and the
interfaces made it really clear what just happened and what might happen next
developing apps with zookeeper would be much more straightforward (or at least
more transparent). Your retry handler is one such example covering a specific
use case but there are others that can be built up from lower level interfaces
around each of the exception cases. Per your design (as i loosely understand
it) all of these exception handlers could be passed to the execute method.
- will
-----Original Message-----
From: Thomas Koch [mailto:[email protected]]
Sent: Friday, November 04, 2011 12:36 PM
To: [email protected]
Cc: Will Johnson
Subject: Re: ANN: Curator - Netflix's ZooKeeper library
Will Johnson:
> Jordan,
>
> I wanted to chime in and say that we ended up writing a similar
> library for our application. For example we have a BreakableLock that
> implements java.util.concurrent.Lock but requires you to provide a
> BrokenLockListener implementation. Naming aside it looks pretty
> similar to your implementaion with the ClientClosingListener. We also have
> similar code for dealing with
> path creation, retry etc. In order to deal with watches we defined a
> Reconnectable interface that users can implement. These
> reconnectables are added to a client and called on session expiration
> or other catastrophic client failures. This gives users a clean way
> to reestablish their watches and reset internal state while
> centralizing all of the error handling.
>
> When we get around to refactoring or expanding our code base we'll
> definitely take a look at using Curator. If nothing else it makes us
> feel good that someone else solved a lot of the same problems in a
> similar fashion.
>
> - will
Hi Will,
could you give more information about your client library? I'd like to include
it in my list of work that people were forced to do to work around the
shortcommings of the current ZooKeeper client API. You'd be number four after
zkclient[1], cages[2] and netflix's Curator. (These projects also add features,
but all of them had to work around the same API.) I've filled ZOOKEEPER-911
that would provide one class for each possible request to the ZooKeeper server.
An instance of such an operation class could then be passed to an execution
strategy.
[1] http://github.com/sgroschupf/zkclient
[2] http://code.google.com/p/cages/
Imagine the equivalent in SQL: This would be a database client library that
forces you to call methods select(), update(), delete(), insert() depending on
what you want to do and throwing exceptions to the calling code.
You don't do this of course but have an object (or SQL literal string)
representing your query and pass this to some execute() method.
We need to wait for 3.4 to come out before work on ZOOKEEPER-911 could continue.
Regards,
Thomas Koch, http://www.koch.ro
