Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Clarification of watch behavior at the Zookeeper Server

Copy link to this message
Re: Clarification of watch behavior at the Zookeeper Server
On Sep 11, 2013, at 2:17 PM, Camille Fournier <[EMAIL PROTECTED]> 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!