This reminds me of a feature request: Persistent watch --
This type of watch would stick around, and doesn't have the gap-in-time problem that the other watchers do. This is particularly useful for exists and children -- less so for data. Such an event could delay, and merge certain changes together to avoid the possible performance issue (e.g. changed children in last 5ms, not each change). It could even just be a client side ZooKeeper API thing that re-registered and kept state to do it for you. I wrote an entire wrapper API called NodeWatcher that tracks a node, keeps its last seen state, registers watches, and does the diff on data and children -- only passing along real changes to the client in a specific callback (e.g. childrenAdded(List children)) not a generic ZK event. The client to this class does not need to deal with any error conditions at all, it only gets a callback when the NodeWatcher knows something has changed. A separate "Session is broken" sequence is initiated elsewhere (another lower level wrapper class), and a client can _optionally_ decide to listen for that event based on its needs. I've found that in about 4 out of 5 use cases, clients don't even need to know that. I'm also building a TreeWatcher that can do this cascaded to all children of a node. Both of these things should really be part of the base API IMO. All the garbage low level error condition details that make ZK a pain in the butt to use is needed for locks, queues, and other synchronization primitives, but is not needed for "watch this node for changes to children or data, and tell me what changed". (this is the basis for an event-driven distributed coordination system -- for many event types all that is required is notification, queues and locks don't apply; for the parts that need it more error handling is exposed to the client) On 5/8/09 1:01 PM, "Benjamin Reed" <br...@yahoo-inc.com> wrote: > i'm adding a faq on this right now. it's a rather common request. > > we could put in the name of the node that is changing. indeed, we did in > the first cut of zookeeper, but then we found that every instance of > programs that used this resulted in bugs, so we removed it. > > here is the problem: > > you do a getChildren(), an event comes in that "foo" is deleted, and > right afterwords "goo" gets deleted, but you aren't going to get that > event since the previous delete fired and you haven't done another > getChildren(). this almost always results in an error, so much so that > we don't even give people the rope. > > ben > > Javier Vegas wrote: >> Hi, I am starting to implement Zookeeper as an arbiter for a high >> performance client-server service, it is working really well but I >> have a question. When my Watcher receives an event of >> NodeChildrenChanged event, is there any way of getting from the event >> the path for the child that changed? The WatchedEvent javadoc says >> that it "includes exactly what happened" but all I am able to extract >> is a vague "NodeChildrenChanged" type. What I am doing now to figure >> out the path of teh new child is to do a new getChildren and compare >> the new children list with the old children list, but that seems a >> waste of time and bandwith if my node has lots of children and is >> watched by a loot of zookeepers (which will be in prod). If I can >> somehow get the path of the added/deleted child from the >> WatchedEvent, it will make my life easier and my Zookeeper-powered >> system much more simple, robust and scalable. Any suggestions? >> >> Thanks, >> >> Javier Vegas >> > >
