On Sep 12, 2013, at 10:57 AM, Ben Bangert <[email protected]> wrote: > Why do the docs conflict with the code on how many types of watches there are?
Answering my own question, the answer seems to be that despite the code suggesting there are existsWatches, these are actually setup to special case a situation (which I'm not entirely sure of). The code is actually adding exist watches to the dataWatches HashMap, unless rc <> 0. I'm not sure what condition is required for that. > 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. This bug will likely never occur, as I think the comment is probably right. It should be impossible for existWatches to ever have anything in it by the time a NodeDelete for the path occurs. Perhaps clever use of SetWatches on a reconnect right as the node is being deleted by another client could cause it.... not sure. Cheers, Ben
