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 W
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
I see the problem, I need to put another watch after I receive the
first event to get notified of the second event. Would it make sense
then to have a watchChildren() method that sets the second watch but
without returning the full children list? That way I can do
getChildren() the first time and t
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 ag
Also note that you are guaranteed to at some event it the file you are
watching changes, but you may get one notification for several changes.
The general pattern of your code should be:
getChildren, set watch
process initial set of children
...
receive notification of chang
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 tog
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 ge
On Fri, May 8, 2009 at 1:31 PM, Javier Vegas 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 a
If you really have thousands of nodes, you may be better off just collecting
all the data into a single document rather than a directory of children.
Zookeeper is fast, but making thousands of calls can eat up some time,
especially if you are debugging a local client with a remote ZK server.
On Fr
There is no gap in time if you put the new watch into the call that gives
you the current version of the data. That is the point of having the watch
argument in all of the get* calls!
On Fri, May 8, 2009 at 1:43 PM, Scott Carey wrote:
> This type of watch would stick around, and doesn't have th
I noticed this today, sounds interesting:
http://cxf.apache.org/
"Apache CXF is an open source services framework. CXF helps you build
and develop services using frontend programming APIs, like JAX-WS. These
services can speak a variety of protocols such as SOAP, XML/HTTP,
RESTful HTTP, or COR
Would it help if we have a seperate API to set a watch on a node, but the
client sends the previous version of the node it saw as a parameter. When the
server sets the watch, if the version of the node is higher than the version
sent by the client, the watch will be triggered immediately. This
On 5/8/09 2:15 PM, "Ted Dunning" wrote:
> There is no gap in time if you put the new watch into the call that gives
> you the current version of the data. That is the point of having the watch
> argument in all of the get* calls!
>
There is a gap in time between when watch A triggers, and whe
You can do this with the current API.
Just call zk.exists() with a watch set and compare the version numbers in
the returned stat field. If they are the same, then no changes happened
before the exists() call and all subsequent changes will be signaled to the
watcher.
On Fri, May 8, 2009 at 5:14
You can use the exists() call to get pretty much what you want.
On Fri, May 8, 2009 at 7:01 PM, Scott Carey wrote:
>
> On 5/8/09 2:15 PM, "Ted Dunning" wrote:
>
> > There is no gap in time if you put the new watch into the call that gives
> > you the current version of the data. That is the
18 matches
Mail list logo
