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!


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

Reply via email to