@hadoop.apache.org
Subject: Re: NodeChildrenChanged WatchedEvent
Making things better is always good.
I have found that in practice, most wrappers of ZK lead to serious errors
and should be avoided like the plague. This particular use case is not a
big deal for me to code correctly (in Java, anyway
Making things better is always good.
I have found that in practice, most wrappers of ZK lead to serious errors
and should be avoided like the plague. This particular use case is not a
big deal for me to code correctly (in Java, anyway) and I do it all the
time.
It may be that the
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
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
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
Maybe the name I selected is confusing, watchForChildrenChanges() is
more descriptive than watchChildren(). The first indicates that I am
setting a watch for children changes, the old name kinds of implies I
am watching for changes on the children of the node, which is not what
I want.
Javier
On
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
This reminds me of a feature request:
Persistent watch --
This type of watch would stick around, and doesn't have the gap-in-time
problem that the other watchers do. This is particularly useful for exists
and children -- less so for data.
Such an event could delay, and merge certain changes
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
On Fri, May 8, 2009 at 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
10 matches
Mail list logo
