It won't work, because when you call watchChildren() you don't actually know the list of children from the previous getChildren() if the initial watch fired.
The initial watch may have fired because child X was added, but by the time you get that message and call your watchChildren(), child Y and Z may have been added as well, and you won't get events for that. So, the pattern is to call getChildren() with a watch, save the list, then when the event fires you call getChildren() again and set a watch, do a diff of the result with the previous result to calculate what was added or removed, do your app specific things as a result, and save the new state for when the next watch fires. On 5/8/09 1:31 PM, "Javier Vegas" <jav...@beboinc.com> wrote: > 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 >>>> >>> >> >