Mailing-List: contact zookeeper-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-user@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=received:user-agent:date:subject:from:to:message-id:
	thread-topic:thread-index:in-reply-to:mime-version:content-type:
	content-transfer-encoding:x-originalarrivaltime;
	b=tE+S7Yb7P9Ynz5QSVmnPl47d8aG7USTpT/VdXyDfc9hcT75sTTXEoDiVzaxTahQ1
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 04 May 2010 15:16:56 -0700
Subject: Re: ZKClient
From: Mahadev Konar <mahadev@yahoo-inc.com>
To: <zookeeper-user@hadoop.apache.org>
Message-ID: <C805EAE8.3522A%mahadev@yahoo-inc.com>
Thread-Topic: ZKClient
Thread-Index: Acrr14GzDOrX3FDNX0qhPOMNY5xAYw==
In-Reply-To: <v2ncf67d0ac1005041458y501cbd3fpe1b5688dd574939@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Hi Adam,
  I don't think zk is very very hard to get right. There are exmaples in
src/recipes which implements locks/queues/others. There is ZOOKEEPER-22 to
make it even more easier for application to use.

Regarding re registration of watches, you can deifnitely write code and
submit is as a part of well documented contrib module which lays out the
assumptions/design of it. It could very well be useful for others. Its just
that folks havent had much time to focus on these areas as yet.

Thanks
mahadev


On 5/4/10 2:58 PM, "Adam Rosien" <adam@rosien.net> wrote:

> I use zkclient in my work at kaChing and I have mixed feelings about
> it. On one hand it makes "easy things easy" which is great, but on the
> other hand I very few ideas what assumptions it makes "under the
> hood". I also dislike some of the design choices such as unchecked
> exceptions, but that's neither here nor there. It would take some
> extensive documentation work by the authors to really enumerate the
> model and assumptions, but the project doesn't seem to be active
> (either from it being adequate for its current users or just
> inactive). I'm not sure I could derive the assumptions myself.
>=20
> I'm a bit frustrated that zk is "very, very hard to really get right".
> At a project level, can't we create structures to avoid most of these
> errors? Can there be a "standard model" with detailed assumptions and
> implementations of all the recipes? How can we start this? Is there
> something that makes this too hard?
>=20
> I feel like a recipe page is a big fail; wouldn't an example app that
> uses locks and barriers be that much more compelling?
>=20
> For the common FAQ items like "you need to re-register the watch",
> can't we just create code that implements this pattern? My goal is to
> live up to the motto: a good API is impossible to use incorrectly.
>=20
> .. Adam
>=20
> On Tue, May 4, 2010 at 2:21 PM, Ted Dunning <ted.dunning@gmail.com> wrote=
:
>> In general, writing this sort of layer on top of ZK is very, very hard t=
o
>> get really right for general use. =A0In a simple use-case, you can probabl=
y
>> nail it but distributed systems are a Zoo, to coin a phrase. =A0The proble=
m is
>> that you are fundamentally changing the metaphors in use so assumptions =
can
>> come unglued or be introduced pretty easily.
>>=20
>> One example of this is the fact that ZK watches *don't* fire for every
>> change but when you write listener oriented code, you kind of expect tha=
t
>> they will. =A0That makes it really, really easy to introduce that assumpti=
on
>> in the heads of the programmer using the event listener library on top o=
f
>> ZK. =A0Another example is how the atomic get content/set watch call works =
in
>> ZK is easy to violate in an event driven architecture because the thread
>> that watches ZK probably resets the watch. =A0If you assume that the liste=
ner
>> will read the data, then you have introduced a timing mismatch between t=
he
>> read of the data and the resetting of the watch. =A0That might be OK or it
>> might not be. =A0The point is that these changes are subtle and tricky to =
get
>> exactly right.
>>=20
>> On Tue, May 4, 2010 at 1:48 PM, Jonathan Holloway <
>> jonathan.holloway@gmail.com> wrote:
>>=20
>>> Is there any reason why this isn't part of the Zookeeper trunk already?
>>>=20
>>=20