zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Bangert <...@groovie.org>
Subject Re: Clarification of watch behavior at the Zookeeper Server
Date Thu, 12 Sep 2013 17:57:19 GMT
On Sep 11, 2013, at 2:17 PM, Camille Fournier <camille@apache.org> wrote:

> "I see from the Java server code that the watches are held at the
> individual server. So if you connect to a new server but the session has
> not expired, the watch is obviously not registered there, so it's sent a
> session event? Which session event?"
> 
> It's sent as a setWatches event, added to the outgoing queue after a
> connection request for the session, then auth (then watches).
> I think the docs are probably imprecise but I don't think this is actually
> about connecting to a NEW server, so much as getting disconnected and
> reconnected at all.

Ah, in this case I'm referring to the client-side events. A "session event" in this case refers
to one of:
- ConnectionLoss
- SessionExpired
- etc.

Or are you saying that 'setWatches' is a type of event that a watcher object will be called
with?

> Inside the server, when you resend those new watches, you send them
> associated with a last seen zxid. They are registered in the server as a
> HashSet to the Watcher object, which is in fact the ServerCnxn that you've
> created with the client. So if for some reason that ServerCnxn object is
> the same it wouldn't actually add anything new but I don't think that can
> ever be the case. It will use that last seen zxid to check if there were
> any changes and send a notification on those changes. The watch will come
> in on the SyncConnected state so you know that this happened while you were
> disconnected.

Just out of curiosity, given that user-code should generally know when it was disconnected,
why would the user care whether the watch event triggered while they were disconnected vs.
any other time? Either way they need to set a new watch if they want to keep monitoring it.

> Yes, it's controlled by a variable and no, I have no idea why.
> 
> I'm sure this isn't answering everything, please feel free to ask
> clarifying questions.


Thanks a bunch, that does help a bit. Though I got a new question...

Why do the docs conflict with the code on how many types of watches there are?

"• A watch object, or function/context pair, will only be triggered once for a given notification.
For example, if the same watch object is registered for an exists and a getData call for the
same file and that file is then deleted, the watch object would only be invoked once with
the deletion notification for the file."

All the docs here (http://zookeeper.apache.org/doc/r3.4.5/zookeeperProgrammers.html#ch_zkWatches)
for watches clearly indicate that there are two types of watches:
- Data watches
- Children watches

All the code indicates there are three types of watches, saying that 'exists' is a separate
watch type. The code however merges exists watches for the same path into data watches (as
it should given what the docs say), but then there's this bizarre comment in the code on line
306 of http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/ZooKeeper.java?view=markup

LOG.warn("We are triggering an exists watch for delete! Shouldn't happen!");

This makes no sense. All the docs indicate exists watches should and will be triggered for
a NodeDelete event (the doc example above specifically uses exists in a delete example!).
After reading the code a bit more, I believe there's also a bug:

301	 // XXX This shouldn't be needed, but just in case
302	 synchronized (existWatches) {
303	 Set<Watcher> list = existWatches.remove(clientPath);
304	 if (list != null) {
305	 addTo(existWatches.remove(clientPath), result);
306	 LOG.warn("We are triggering an exists watch for delete! Shouldn't happen!"); 
307	 }
308	 }

Line 303 removes the watch, so line 305's return will be a null, no?. I believe line 305 should
be adding the new list made on line 303.

The C code treats exists watchers identically, though for whatever reason, it still stores
them separately. The C code does not have any odd warning lines about triggering an exist
watch for a delete. Line 308 of http://svn.apache.org/viewvc/zookeeper/trunk/src/c/src/zk_hashtable.c?revision=1353683&view=markup.

Thanks a bunch for clearing up how the watches are re-registered!

Cheers,
Ben


Mime
View raw message