hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: ZKClient
Date Tue, 04 May 2010 22:45:47 GMT
Travis,

Attachments are stripped from this mailing list.  Can you file a JIRA and
put your attachment on that instead?

Here is a link to get you started:
https://issues.apache.org/jira/browse/ZOOKEEPER

On Tue, May 4, 2010 at 3:43 PM, Travis Crawford <traviscrawford@gmail.com>wrote:

> Attached is a skeleton application I extracted from a script I use --
> perhaps we could add this as a recipe? If there are issues I'm more
> than happy to fix them, or add more comments, whatever. It took a
> while to figure this out and I'd love to save others that time in the
> future.
>
> --travis
>
>
> On Tue, May 4, 2010 at 3:16 PM, Mahadev Konar <mahadev@yahoo-inc.com>
> wrote:
> > 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.
> >>
> >> 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?
> >>
> >> 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?
> >>
> >> 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.
> >>
> >> .. Adam
> >>
> >> 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
> to
> >>> get really right for general use.  In a simple use-case, you can
> probably
> >>> nail it but distributed systems are a Zoo, to coin a phrase.  The
> problem is
> >>> that you are fundamentally changing the metaphors in use so assumptions
> can
> >>> come unglued or be introduced pretty easily.
> >>>
> >>> 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
> that
> >>> they will.  That makes it really, really easy to introduce that
> assumption
> >>> in the heads of the programmer using the event listener library on top
> of
> >>> ZK.  Another 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.  If you assume that the
> listener
> >>> will read the data, then you have introduced a timing mismatch between
> the
> >>> read of the data and the resetting of the watch.  That might be OK or
> it
> >>> might not be.  The point is that these changes are subtle and tricky to
> get
> >>> exactly right.
> >>>
> >>> On Tue, May 4, 2010 at 1:48 PM, Jonathan Holloway <
> >>> jonathan.holloway@gmail.com> wrote:
> >>>
> >>>> Is there any reason why this isn't part of the Zookeeper trunk
> already?
> >>>>
> >>>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message