zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Johnson <w...@attivio.com>
Subject RE: ANN: Curator - Netflix's ZooKeeper library
Date Fri, 04 Nov 2011 16:53:26 GMT
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:thomas@koch.ro] 
Sent: Friday, November 04, 2011 12:36 PM
To: user@zookeeper.apache.org
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

Mime
View raw message