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 []
Sent: Saturday, May 09, 2009 1:06 PM
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 <>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)

Reply via email to