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.
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?