Menu
▾
▴
Re: [Zookeeper-user] [Bug?] Notification not guaranteed
|
From: Bartlomiej N. <ba...@ya...> - 2008-04-25 22:54:10
|
Thanks Mahadev, That sounds reasonable; we already have a case in our cluster library when we would use permanent watches. I understand your points, but I also got feeling from Ben that subscriptions are something that is not going to happen soon. B. -----Original Message----- From: Mahadev Konar Sent: Friday, April 25, 2008 3:38 PM To: Bartlomiej Niechwiej; Benjamin Reed; Jacob Levy; Ted Dunning; Benjamin Reed Cc: zoo...@li... Subject: RE: [Zookeeper-user] [Bug?] Notification not guaranteed HI Bart, There is no reason not to have both. We could say Subscribe to the node and "yes" I want the data as well. Or Subscribe to the node and "no" I am just interested in notifications. We are just discussing what to implement and a more general use case. We know that what you ask is useful and would clearly want to do that but just discussing if something more useful can be done which is general enough. Regards Mahadev > -----Original Message----- > From: zoo...@li... [mailto:zookeeper-user- > bo...@li...] On Behalf Of Bartlomiej Niechwiej > Sent: Friday, April 25, 2008 3:29 PM > To: Benjamin Reed; Jacob Levy; Ted Dunning; Benjamin Reed > Cc: zoo...@li... > Subject: Re: [Zookeeper-user] [Bug?] Notification not guaranteed > > Ben, I think I gave a clear example that I was interesting in > notifications about the change, not about the data being changed. In > other words, the presence or absence is my data, a boolean. In the > scenario I described, zookeeper cannot provide a reliable way of giving > me what I need. That's it. > > Why it is so hard to provide a permanent server side watches? What is > the problem with that? Is it that we don't want this functionality > because it doesn't make sense or is it just a theoretical discussion? > > You suggest subscriptions mechanism, which is way too much expensive > versus what I propose, and for simple cases like the one described, you > would have to end up spending too much ZK resources. > > B. > > -----Original Message----- > From: Benjamin Reed [mailto:br...@ya...] > Sent: Friday, April 25, 2008 2:29 PM > To: Jacob Levy; Ted Dunning; Bartlomiej Niechwiej; Benjamin Reed > Cc: zoo...@li... > Subject: Re: [Zookeeper-user] [Bug?] Notification not guaranteed > > 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? > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j av > aone > _______________________________________________ > Zookeeper-user mailing list > Zoo...@li... > https://lists.sourceforge.net/lists/listinfo/zookeeper-user |
