zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jzimmer...@netflix.com>
Subject RE: ANN: Curator - Netflix's ZooKeeper library
Date Tue, 11 Oct 2011 23:34:03 GMT
It amazes me that people comment on this or that library that it's too complicated but then
don't blanch to use things such as Maven, Guice, Spring, Hibernate, etc. 

Issues with zkClient:
* Very poor documentation (is there any?)
* Far too coupled for my taste. zkClient covers far too much scope. 
* Error handling is very weak (everything becomes RuntimeException)
* Hard coded retry mechanism
* Some bad anti-patterns
** ZkClient constructor leaks "this" ref
** lots of synchronized/lock blocks

Curator is much more modular. You could use just the Client package (which isn't complicated
at all). The recipes are completely de-coupled making them more reusable/extendable. I believe
a new ZK user would have a much easier time with Curator than zkClient. My experience with
users at Netflix confirms this. Our users can concentrate on the recipes (which is what they're
really interested in) and not worry about the details of managing ZK interaction.

From: Camille Fournier [camille@apache.org]
Sent: Tuesday, October 11, 2011 4:00 PM
To: user@zookeeper.apache.org
Subject: Re: ANN: Curator - Netflix's ZooKeeper library

My first reaction to the code, also at a high-level browse, was that it is
way over-complicated. Might just be the builder style, which I also don't
care for. I had to go several levels deep through interfaces and impls to
see the code that does anything of meaning, which makes for a high learning
curve and a debugging headache.

So, it's not clear to me why anyone would use this over zkClient, except
that you have provided a pluggable retry style, which is nice. Any other
major benefits I'm missing from a scan?

On Oct 11, 2011 4:53 PM, "Jordan Zimmerman" <jzimmerman@netflix.com> wrote:

> The major raison d'ĂȘtre for Curator is to make adding "recipes" much
> easier. Using the Curator Framework APIs you can easily build new
> usages/recipes and not worry about connection management.
> -JZ
> On 10/11/11 1:46 PM, "Ted Dunning" <ted.dunning@gmail.com> wrote:
> >What I prefer to see in this context is a method that takes a closure that
> >does the desired mutation and which encapsulates the necessary read,
> >modify,
> >write, retry logic.

View raw message