zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Camille Fournier <cami...@apache.org>
Subject Re: ANN: Curator - Netflix's ZooKeeper library
Date Tue, 11 Oct 2011 23:51:55 GMT
You asked for feedback, I gave it. You know nothing about what I think
of maven, guice, spring, or hibernate, so why bring them up?

There's a middle ground between Curator and zkClient, and I personally
would love to see that middle ground reached. Anyway, I've never made
a decision to use a library or not based on the conditions you listed
below (unless there were actual usability issues related to them,
which for me there weren't in zkClient), so I'm pretty sure I am not
your target audience. But I know there are many here that would be
turned off by those reasons and it is great to give them a different
choice.

C

On Tue, Oct 11, 2011 at 7:34 PM, Jordan Zimmerman
<jzimmerman@netflix.com> wrote:
> 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.
>
> -JZ
> ________________________________________
> 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?
>
> C
> 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.
>>
>>
>

Mime
View raw message