Sorry, what I meant is issuing the new method watchChildren() on the parent node (basically the same as getChildren() but returning just a boolean instead of a list of children, because I already know the paths of the original children and the ones that were added/deleted so I dont need the list again). I wasnt thinking (yet) about grandchildren, but If I want to watch for them, I will need to do a initial getChildren() on the new child that NodeChildrenChanged told me about, followed by a watchChildren() after each event. Does this make sense?
Javier On Fri, May 8, 2009 at 1:23 PM, Patrick Hunt <ph...@apache.org> wrote: > Javier, also note that the subsequent getChildren you mention in your > original email is usually not entirely superfluous given that you generally > want to watch the parent node for further changes, and a getChildren is > required to set that watch. > > Patrick > > Benjamin Reed 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 >>> >> >
