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
