zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: Question about watcher guarantees
Date Wed, 14 Mar 2012 15:55:55 GMT
On Wed, Mar 14, 2012 at 5:06 AM, Carroll, Jim <Jim.Carroll@navteq.com> 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
> 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,

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.


View raw message