I found two places in the documentation that explain that I can miss change events in watchers due to the "one-time" nature of set watches. This makes sense. However, some of the examples (e.g. Barrier) assume that at least the default watcher will never miss a change event.

Can I safely make that assumption about the default watcher?

If so, can I use the "path" information to avoid the "flood" of clients getting the current state of the node hierarchy? For example, if I assume I wont miss any events in the main watcher and I get a NodeCreated event with the path, can I simply update my client with that information and assume I'm up to date? This would run contrary to the answer provided for the FAQ question with the label "Why doesn't the NodeChildrenChanged and NodeDataChanged watch events return more information about the change?"

Thanks
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.

On Wed, Mar 14, 2012 at 5:06 AM, Carroll, Jim <[EMAIL PROTECTED]> wrote:
>
> I found two places in the documentation that explain that I can miss change events in watchers due to the "one-time" nature of set watches. This makes sense. However, some of the examples (e.g. Barrier) assume that at least the default watcher will never miss a change event.
>
> Can I safely make that assumption about the default watcher?
>

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.

> If so, can I use the "path" information to avoid the "flood" of clients getting the current state of the node hierarchy? For example, if I assume I wont miss any events in the main watcher and I get a NodeCreated event with the path, can I simply update my client with that information and assume I'm up to date? This would run contrary to the answer provided for the FAQ question with the label "Why doesn't the NodeChildrenChanged and NodeDataChanged watch events return more information about the change?"

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...

Say there is a counter /foo = 1, /foo = 2, /foo = 3 etc... Your client
may see 1, 2, 3, or it may just see 1,3. However in either case you're
guaranteed that if you use the process I listed in the previous para
you'll not miss that something changed.

Patrick

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.

On Wed, Mar 14, 2012 at 9:22 AM, Carroll, Jim <[EMAIL PROTECTED]> wrote:
>>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.

See the recipes page for some examples of how to avoid herd effects.
Sometimes it's possible, but not always:
http://zookeeper.apache.org/doc/trunk/recipes.html

Patrick

On Wed, Mar 14, 2012 at 12:50 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> > 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.
>
> See the recipes page for some examples of how to avoid herd effects.
> Sometimes it's possible, but not always:
> http://zookeeper.apache.org/doc/trunk/recipes.html
I would add that sometimes it is important, but not always.