Re: [Zookeeper-user] [Bug?] Notification not guaranteed

[Benjamin R. <br...@ya...>]

Here is the issue: are you watching for changes or just the notification that something changed? Watches are really about notification of changes. Imagine the following execution:

time 0: set /a to value0 (now version 1)
time 1: set /a to value1 (now version 2)
time 2: set /a to value2 (now version 3)
time 3: set /a to value3 (now version 4)
time 4: set /a to value4 (now version 5)

If we had a permanent watch a client watching /a would get:

time 0: getData(/a, permanent)
time 1: getData returns value1 version 2
time 2: /a changed
time 3: /a changed
time 4: /a changed

With our current watches you could see something like:

time 0: getData(/a, true)
time 1: getData returns value1 version 2
time 2: /a changed
time 3: getData(/a, true)
time 4: getData returns value4 version 5

Now note, at the client you can change the above into a permanent watch by generating locally missed events by calculating the number of missed changes by subtracting the version numbers:

time 0: getData(/a, true)
time 1: getData returns value1 version 2
time 2: /a changed
time 3: getData(/a, true)
time 4: getData returns value4 version 5 by looking at the version numbers we see that we missed 2 events, so generate now
time 4: /a changed (locally generated)
time 4: /a changed (locally generated)

There is a slight additional latency for the version 4 change, but in some sense we have compressed the traffic (the collapsing that Ted mentioned).

Now, in the end this is all silly. If you are really watching /a in this way, you are probably more interested in the actual data, something that the watch doesn't give you. In that case you usually want the latest value. (This is what ZooKeeper makes easy right now.) or all the intermediate values. Watch events don't have values, so the permanent watches don't help with intermediate values. Subscribe events would push values. Subscribe actually gives you something you cannot get today. 

This is a repeat of what is said on http://zookeeper.wiki.sourceforge.net/SubscribeMethod Does this help clarify the wiki any better?

ben


----- Original Message ----
From: Jacob Levy <jy...@ya...>
To: Ted Dunning <tdu...@ve...>; Bartlomiej Niechwiej <ba...@ya...>; Benjamin Reed <br...@ya...>
Cc: zoo...@li...
Sent: Friday, April 25, 2008 1:12:57 PM
Subject: Re: [Zookeeper-user] [Bug?] Notification not guaranteed

In case noone answered your question yet:

A permanent watch (subscription) will guarantee that the client sees
EVERY change in the thing being watched after the time the permanent
watch is established. A one time watch that is reasserted every time you
read is different, since it can miss events between the time that the
watch fired and is reasserted.

--Jacob


-----Original Message-----
From: zoo...@li...
[mailto:zoo...@li...] On Behalf Of Ted
Dunning
Sent: Friday, April 25, 2008 11:31 AM
To: Bartlomiej Niechwiej; Benjamin Reed
Cc: zoo...@li...
Subject: Re: [Zookeeper-user] [Bug?] Notification not guaranteed


Bartlomiej,

How is a watch that is always reasserted on every read different from a
permanent watch?  The client side implementation has the virtue that it
collapses multiple changes if the client goes away or gets busy.

Is it just a client API issue?