zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Carey <sc...@richrelevance.com>
Subject Re: NodeChildrenChanged WatchedEvent
Date Fri, 08 May 2009 20:38:15 GMT
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" <javier@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 <phunt@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
>>>> 
>>> 
>> 
> 


Mime
View raw message