[Zookeeper-developer] [ zookeeper-Patches-1937078 ] Passing a watch object to read requests

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Patches item #1937078, was opened at 2008-04-07 14:21
Message generated for change (Comment added) made by breed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: java client
Group: 3.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benjamin Reed (breed)
Assigned to: Patrick Hunt (phunt)
Summary: Passing a watch object to read requests

Initial Comment:
When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods.

----------------------------------------------------------------------

>Comment By: Benjamin Reed (breed)
Date: 2008-05-27 13:26

Message:
Logged In: YES 
user_id=154690
Originator: YES

'Are you saying that if I call getData(node,true) and exists(node,true)
and
then a subsequent create(node) happens I will get a single watch event of
type datachanged for node? I won't see a "datachanged(node)" as well as a
"nodecreated(node)", one for each of the read calls respectively?'

If a create(node) succeeds, that means the node did not exists, which
means that getData got a NoNode error, which means that no watch was set.
So, you will only see a nodecreated event and it would be delivered to the
Watcher of the exists() call.

----------------------------------------------------------------------

Comment By: Patrick Hunt (phunt)
Date: 2008-05-27 12:48

Message:
Logged In: YES 
user_id=12853
Originator: NO

What would you suggest regarding async read requests and watcher
registration - we wrap the callback with code that registers the watcher
then calls the client callback? I think this would be cleaner than
embedding into the clientcnxn EventThread code. What do you think?

----------------------------------------------------------------------

Comment By: Patrick Hunt (phunt)
Date: 2008-05-27 12:40

Message:
Logged In: YES 
user_id=12853
Originator: NO

Hm. I re-read the docs and I'm still a bit confused by your statements
regarding watch types.

Are you saying that if I call getData(node,true) and exists(node,true) and
then a subsequent create(node) happens I will get a single watch event of
type datachanged for node? I won't see a "datachanged(node)" as well as a
"nodecreated(node)", one for each of the read calls respectively?

The watches wiki http://zookeeper.wiki.sourceforge.net/ZooKeeperWatches
should really be beefed up with more detail on which event types are
generated based on write ops.

----------------------------------------------------------------------

Comment By: Patrick Hunt (phunt)
Date: 2008-05-27 12:07

Message:
Logged In: YES 
user_id=12853
Originator: NO

I'll rework the patch. Regarding the c vs java - I only implemented java
due to the category being set to "java client". Perhaps we should add a
"client API" category? Or maybe create two requests instead of 1 -- would
be better for me since I'm much more familiar with java than C, you could
assign to someone better able to execute. :-)

----------------------------------------------------------------------

Comment By: Benjamin Reed (breed)
Date: 2008-05-27 11:22

Message:
Logged In: YES 
user_id=154690
Originator: YES

We do also need to implement this in the C client as well, but for
simplicity we should make that a separate patch.

We shouldn't add watches to the watches hashmap until we get a successful
result back from the server. Otherwise, we might trigger watches for things
that the client isn't expecting.

There is also a problem with type watch types. In the server we have a
watch list for data and child watches. It might be good to keep that same
division in the client. (Either way would work though.)

a watch on getChildren() can result in a childrenChanged or nodeDeleted
watch event.
getData() can result in dataChanged or nodeDeleted event.
exist() can result in dataChanged, nodeCreated, or nodeDeleted event.

getChildren() and getData() will not get nodeCreated events, because non
existence is an error condition for those two calls and a watch will not be
set.

----------------------------------------------------------------------

Comment By: Patrick Hunt (phunt)
Date: 2008-05-22 14:09

Message:
Logged In: YES 
user_id=12853
Originator: NO

Here's the patch, assigning to Ben for further review.

Please pay particular attention to the handling of state changes - I clear
the watch table when we are not sync'd to the server. Verify my workflow.

File Added: watcherobj.patch

----------------------------------------------------------------------

Comment By: Patrick Hunt (phunt)
Date: 2008-05-20 23:18

Message:
Logged In: YES 
user_id=12853
Originator: NO

I've implemented this for Java. I overloaded the respective methods with
signatures that take watcher object instead of watch boolean. I added new
methods rather than replacing -- this maintains b/w compatibility.

1) should I mark the old methods as deprecated or should we just support
both method types (newer signature w/ explicit watcher object && old watch
boolean which directs to the "global" watcher.)

2) I see this is listed as category "java client" so I'm assuming there is
no need for this feature in c code interface.

----------------------------------------------------------------------

Comment By: Patrick Hunt (phunt)
Date: 2008-05-20 17:52

Message:
Logged In: YES 
user_id=12853
Originator: NO

I was specifically referring to the client api, not the protocol -- should
I assume that that last watcher on a particular node "wins". What I mean is
if a client calls "getChildren(path, watcherobj1); getChildren(path,
watcherobj2);" (notice same patch) what should the client lib do? I'm
assuming use the last watcher, but wanted to verify.

----------------------------------------------------------------------

Comment By: Benjamin Reed (breed)
Date: 2008-05-19 19:05

Message:
Logged In: YES 
user_id=154690
Originator: YES

The client will need to track the multiple watcher objects to invoke when
it gets the callback. The client server protocol doesn't change, this is
just a client side thing. We should add the ability to remove watches as a
separate feature request.

----------------------------------------------------------------------

Comment By: Patrick Hunt (phunt)
Date: 2008-05-14 00:21

Message:
Logged In: YES 
user_id=12853
Originator: NO

What should we do if the user calls getData multiple times with different
watcher objects? Remove previous watch and replace with new watcher, throw
error, or allow multiple watchers on particular node? How about removing a
watch by calling method on particular node with null watcher?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147