zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carroll, Jim" <Jim.Carr...@navteq.com>
Subject RE: Question about watcher guarantees
Date Wed, 14 Mar 2012 16:22:18 GMT
Patrick,

Thanks for the response.

>No. Watches are one time triggers that fire on a znode change, any
>further changes (on the znode, based on watch type) are not notified
>until that particular watch is re-established. This is regardless of
>whether a default or non-default watcher is used.

Thanks. This is what I originally thought except, when reading the barrier example, I misinterpreted
it.

Thanks for the clarification.

>Not sure I follow. However the typical use case, let's say for a data
>watch, is to 1) getData("/foo", true)  2) wait for the watch to fire
>3) then do another getData("/foo", true).  If multiple changes
>occurred btw 2 and 3 you will see the results when 3 returns. If there
>are subsequent changes after 3 you'll receive another notification,
>etc...

This means there's not really any way to avoid the "flood" of client get-state requests (getData/getChildren/exists)
that will happen when a change triggers a watcher. In your example a getData call will happen
in every client at step (2) whenever a change happens. There's no way to avoid it. I'm Ok
with that, it's just that the documentation (at some place I cant seem to find now) says to
try to avoid this.

Thanks again.
Jim


The information contained in this communication may be CONFIDENTIAL and is intended only for
the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby
notified that any dissemination, distribution, or copying of this communication, or any of
its contents, is strictly prohibited.  If you have received this communication in error, please
notify the sender and delete/destroy the original message and any copy of it from your computer
or paper files.

Mime
View raw message