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. ben 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.dunn...@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 time. 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 good. On Sat, May 9, 2009 at 12:37 PM, Scott Carey <sc...@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 DeepDyve 111 West Evelyn Ave. Ste. 202 Sunnyvale, CA 94086 www.deepdyve.com 858-414-0013 (m) 408-773-0220 (fax)
