zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Reed <br...@yahoo-inc.com>
Subject RE: NodeChildrenChanged WatchedEvent
Date Mon, 11 May 2009 15:20:28 GMT
good summary ted. just to add a bit. another motivation for the current design is what scott
had mentioned earlier: not sending a flood of changes when the value of a node is changing
rapidly. implicit in this is the fact that we do not send the value in the events. not only
does this make the events much more heavy weight, but it also leads to bad programming practices
(see the faq). since we don't send data in the events, sending 3 "data changed" events in
a row is the same as just sending the last "data changed" event.

i also agree with ted about the wrappers. unless they are used to implement a new construct,
usually they just introduce bugs. however, there are two things i want to point out. first,
the current exception handling ranges from a pain to, in the case of create() with SEQUENTIAL
and EPHEMERAL, almost impossible, so we want to make connecting recovery a bit more sophisticated;
when a connection goes down, the client and server figure out what happen to the pending requests
so that we never need to error them out with the "i have no idea what happened" exception,
aka CONNECTION LOSS. second, higher level constructs in the form of recipes are great! for
more sophisticated constructs it is great to have things implemented once and thoroughly debugged.


ps - one other clarification in ZK 3, the watches are still tracked locally. it's just that
in ZK 3 the client now has the ability to tell the server what it was watching and what was
the last thing seen when it reconnects. the server can then figure out which watches were
missed and need to be retriggered and which watches need to be reregistered
From: Ted Dunning [ted.dunning@gmail.com]
Sent: Saturday, May 09, 2009 1:06 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: NodeChildrenChanged WatchedEvent

Making things better is always good.

I have found that in practice, most wrappers of ZK lead to serious errors
and should be avoided like the plague.  This particular use case is not a
big deal for me to code correctly (in Java, anyway) and I do it all the

It may be that the no-persistent-watch policy was partly an artifact of the
ZK 1 and ZK 2 situation where ZK avoided keeping much of anything around per
session other than ephemeral files.  This has changed in ZK 3 and it might
be plausible to have more persistent watches.

On the other hand, I believe that Ben purposely avoided having this type of
watch to automatically throttle the number of notifications to be equal to
the rate at which the listener can handle them.  Having seen a number of
systems that didn't throttle this way up close and personal, I have lots of
empathy which that position.  Since I don't have any issue with looking at
for changes, I would tend to just go with whatever Ben suggests.  His
opinions (largely based on watching people code with ZK) are pretty danged

On Sat, May 9, 2009 at 12:37 PM, Scott Carey <scott@richrelevance.com>wrote:

> What I am suggesting are higher level constructs that do these repeated
> mundane tasks for you to handle those use cases where the verbosity of the
> API is a hinderance to quality and productivity.

Ted Dunning, CTO

111 West Evelyn Ave. Ste. 202
Sunnyvale, CA 94086
858-414-0013 (m)
408-773-0220 (fax)

View raw message