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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I actually understood your point.  I just disagreed.  That is different.

I still think that Ben's design with one-time watches is magnificently
better (for *almost* all use cases).  Empirical evidence indicates that its
superior qualities are unfortunately subtle, however.

(but that just feeds into my arrogance by making me think I see a subtlety
that many others do not.  My only impetus to humility is that Ben knew this
truth long before I heard it from him)

(joke)

On 4/25/08 1:12 PM, "Jacob Levy" <jy...@ya...> wrote:

> 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?
> 
> 
> On 4/25/08 10:26 AM, "Bartlomiej Niechwiej" <ba...@ya...> wrote:
> 
>> Thanks, Ben. 
>> 
>> However subscriptions are significantly different from watches (they
>> provide data as well), so I don't consider them as permanent watches
> per
>> se.
>> 
>> Basically, there are two use cases here, (1) if you are interested in
>> existence of a node, rather than in the data it carries on and (2) in
>> being notified about data changes of a node. For (1) you essentially
>> need a permanent watch, as you don't care about the data, while for
> (2)
>> subscriptions is a must. It'd be worth to support both mechanisms at
> the
>> same time. It's conceivable that a permanent watch is much cheaper
> than
>> a subscription.
>> 
>> I'm not sure how the watches are implemented now, but I would be
>> surprised if supporting permanent watches would require more than a
> few
>> minutes of work (instead of removing the watch after sending an event,
>> you would have to keep it or re-register again, plus we would need a
> way
>> to pass information whether a watch is permanent or one-time).
>> 
>> Bart
>> 
>> 
>> -----Original Message-----
>> From: Benjamin Reed [mailto:br...@ya...]
>> Sent: Friday, April 25, 2008 10:16 AM
>> To: Bartlomiej Niechwiej
>> Cc: zoo...@li...
>> Subject: Re: [Zookeeper-user] [Bug?] Notification not guaranteed
>> 
>> We call permantent watches subscriptions see
>> (http://zookeeper.wiki.sourceforge.net/SubscribeMethod). I really want
>> to do 
>> it and I think it would be very useful and more than a convenience it
>> actually provides more functionality. Unfortunately, we just don't
> have
>> the 
>> bandwidth right now to implement it. The fortunate thing is that it is
>> "just 
>> a matter of programming" all the information is there and all the
> needed
>> 
>> information is already being replicated and saved in the transaction
>> log.
>> 
>> ben
>> 
>> On Friday 25 April 2008 10:01:40 Bartlomiej Niechwiej wrote:
>>> Ben,
>>> 
>>> I think the best approach would be to support permanent watches, a
>>> feature which has been asked for since the very beginning...
>>> 
>>> Not only would it cease the endless discussion of naming, but it
> would
>>> also provide a powerful feature ;-)
>>> 
>>> Just a thought ;-)
>>> 
>>> B.
>>> 
>>> -----Original Message-----
>>> From: zoo...@li...
>>> [mailto:zoo...@li...] On Behalf Of
>>> Benjamin Reed
>>> Sent: Friday, April 25, 2008 8:48 AM
>>> To: zoo...@li...
>>> Subject: Re: [Zookeeper-user] [Bug?] Notification not guaranteed
>>> 
>>> Naming and the semantics it implies can be an endless argument.
> Unless
>>> we call
>>> it a one time trigger I think people will think of SQL triggers which
>>> are not
>>> one time. (I'm not saying that watch is any better.)
>>> 
>>> I agree about the java doc clarifications. I've been working on it
>> since
>>> Ted
>>> brought it up, but I've been side tracked by the session loss bug.
> I'm
>>> hoping
>>> to finish up today. I'll make sure the javadoc emphasizes the way
>>> watches
>>> work.
>>> 
>>> ben
>>> 
>>> On Friday 25 April 2008 00:14:11 Patrick Hunt wrote:
>>>> Benjamin Reed wrote:
>>>>> This is really a key point for new users to understand, so any
>>> 
>>> pointers
>>> 
>>>>> on how we can clarify that page would be very helpful!
>>>> 
>>>> Part of the issue may be the naming itself. For whatever reason I
>>>> associate "watch" with something long lived - not a "one time
>>>> notification" which I would associate more naturally with "trigger".
>>>> 
>>>> I jumped in right way and started using the java client/server. The
>>> 
>>> java
>>> 
>>>> client javadoc in particular is not clear about watches being "one
>>> 
>>> time
>>> 
>>>> notifications". Would def help to fix the javadoc on this point.
>>>> 
>>>> Patrick
>>>> 
>>>>> ----- Original Message ----
>>>>> From: Stefan Groschupf <sg...@10...>
>>>>> To: zoo...@li...
>>>>> Sent: Thursday, April 24, 2008 10:19:16 PM
>>>>> Subject: [Zookeeper-user] [Bug?] Notification not guaranteed
>>>>> 
>>>>> Hi there,
>>>>> as far I understand notification is guaranteed for e.g. child
>>> 
>>> creation.
>>> 
>>>>> However I have a test that shows that randomly I do not get all
>>>>> notification I do expect.
>>>>> I basically create 10 child in /folder but only get 8 or 9
>>>>> notifications back.
>>>>> However in case I add a Thread.sleep(50); between my child znode
>>>>> creation I always get 10 notifications.
>>>>> 
>>>>> Is that a bug or an optimization, e.g. getting one notification
>> for
>>>>> two new sub znode creations?
>>>>> Thanks for any hints.
>>>>> Stefan
>>>>> 
>>>>> My code looks like this:
>>>>> 
>>>>> TestMethod:
>>>>> 
>>>>>   public void testNotifications() throws Exception {
>>>>>          KattaConfiguration conf = new KattaConfiguration();
>>>>>          Server server = new Server(conf);
>>>>>          ZKClient client = new ZKClient(conf);
>>>>>          MyListener listener = new MyListener();
>>>>>          String katta = "/katta";
>>>>>          if (client.exists(katta)) {
>>>>>              client.deleteRecursiv(katta);
>>>>>          }
>>>>>          client.create(katta);
>>>>>          client.subscribeChildChanges(katta, listener);
>>>>>          for (int i = 0; i < 10; i++) {
>>>>>              client.create(katta + "/" + i);
>>>>> //            Thread.sleep(50);
>>>>>          }
>>>>>          Thread.sleep(1000);
>>>>>          assertEquals(10, listener._counter);
>>>>>          server.shutdown();
>>>>>      }
>>>>> 
>>>>> Watcher process Method:
>>>>> 
>>>>>      public void process(WatcherEvent event) {
>>>>>          synchronized (_mutex) {
>>>>>              String path = event.getPath();
>>>>>               if (event.getType() ==
>>>>> Watcher.Event.EventNodeChildrenChanged) {
>>>>>                  HashSet<IZKEventListener> listeners =
>>>>> _childListener.get(path);
>>>>>                  if (listeners != null) {
>>>>>                      for (IZKEventListener listener : listeners) {
>>>>>                          listener.process(event);
>>>>>                      }
>>>>>                      // re subscribe to event.
>>>>>                      try {
>>>>>                          _zk.getChildren(event.getPath(), true);
>>>>>                      } catch (Exception e) {
>>>>>                          for (IZKEventListener listener :
>> listeners)
>>> 
>>> {
>>> 
>>>>>                              removeListener(path, listener);
>>>>>                          }
>>>>>                          Logger.warn("unable to re subscribe to
>>> 
>>> child
>>> 
>>>>> change notification", e);
>>>>>                      }
>>>>>                  }
>>>>>              }
>>>>>          }
>>>>>      }
>>>>> 
>>>>> 
>>>>> 
>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>> 101tec Inc.
>>>>> Menlo Park, California, USA
>>>>> http://www.101tec.com
>>> 
>>> 
>> 
> ------------------------------------------------------------------------
>>> -
>>> 
>>>>> 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
>>> a
>>> 
>>>>> vaone _______________________________________________
>>>>> Zookeeper-user mailing list
>>>>> Zoo...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
>>> 
>>> 
>> 
> ------------------------------------------------------------------------
>>> -
>>> 
>>>>> 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
>>> a
>>> 
>>>>> vaone _______________________________________________
>>>>> Zookeeper-user mailing list
>>>>> Zoo...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
>>> 
>>> 
>> 
> ------------------------------------------------------------------------
>>> -
>>> 
>>>> 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
>>> ava
>>> 
>>>> one _______________________________________________
>>>> Zookeeper-user mailing list
>>>> Zoo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
>>> 
>>> 
>> 
> ------------------------------------------------------------------------
>>> -
>>> 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
>>> avaone
>>> _______________________________________________
>>> Zookeeper-user mailing list
>>> Zoo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
>> 
>> 
>> 
>> 
> ------------------------------------------------------------------------
> -
>> 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
> avaone
>> _______________________________________________
>> Zookeeper-user mailing list
>> Zoo...@li...
>> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
> 
> 
> ------------------------------------------------------------------------
> -
> 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
> avaone
> _______________________________________________
> Zookeeper-user mailing list
> Zoo...@li...
> https://lists.sourceforge.net/lists/listinfo/zookeeper-user