zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: NodeChildrenChanged WatchedEvent
Date Fri, 08 May 2009 20:23:03 GMT
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.


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

View raw message