Ok, thanks for convincing me that I need to do another getChildren() after each event. My initial plan was to put thousands of children under the same node, but it seems I will need to organize them on some kind of hierarchical structure. I will need to watch lots of nodes not just one, but each getChildren after a watch change will return a small list instead of a humongous one.
Your input was extremely helpful and fast, than you! Javier On Fri, May 8, 2009 at 1:38 PM, Scott Carey <sc...@richrelevance.com> wrote: > 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 >>>>> >>>> >>> >> > >
