Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id E06BE200BBD for ; Tue, 25 Oct 2016 00:16:03 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id DF06E160B01; Mon, 24 Oct 2016 22:16:03 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B50EF160AEB for ; Tue, 25 Oct 2016 00:16:02 +0200 (CEST) Received: (qmail 57540 invoked by uid 500); 24 Oct 2016 22:16:01 -0000 Mailing-List: contact user-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.apache.org Delivered-To: mailing list user@curator.apache.org Received: (qmail 57530 invoked by uid 99); 24 Oct 2016 22:16:01 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Oct 2016 22:16:01 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 76D48C04BB for ; Mon, 24 Oct 2016 22:16:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id k-mCnFQqmm1o for ; Mon, 24 Oct 2016 22:15:59 +0000 (UTC) Received: from mail-yb0-f178.google.com (mail-yb0-f178.google.com [209.85.213.178]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 36A2B5FBDC for ; Mon, 24 Oct 2016 22:15:59 +0000 (UTC) Received: by mail-yb0-f178.google.com with SMTP id f97so85530139ybi.1 for ; Mon, 24 Oct 2016 15:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RcahNbYoIuPAJJf0/Psv0NbnJgnA+2xkr4b6zdRnlfw=; b=bjdxTt+l0rBzdoGHfb0Xpc6YR6vNADYXaCOIbVuzQzGlCPuYpbmdWbQSX+j4IOYOZR CL2xaAdMFTFqf0IO5IiwLndhFet/mRYLUOo/pwdqur2EmibEW+j53DFA+qD971eG+Q/a vl4qhqXIR3TO9KFskZwflRkFquCD1TjB0TElGH+i/MDJQ9l2vwA/11KKRgTXYhVofRT/ AEPNN/DTLJr6zndQAhkJum0tEHcpSd5gLC5oljDoOJcRHCnj7QZEcQD5ecixTdrq+jbd +0vTDy6I6ERq0UFy7KwfFu30uxrT8jFE7oI3KQ1TvYVKEo+lZOhRczI/vKA74snqUoWI 24bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=RcahNbYoIuPAJJf0/Psv0NbnJgnA+2xkr4b6zdRnlfw=; b=Ac1Z1P34emomz9t0C+EtnQoF8e048qqGFioo0V/2KL4w0VWDHDMWi32I1veDMqw+Cm 0S+gIEJREk2xfsk2AI98YSrJ9fa68XOlocCwQ2JvNPXBhCKSBsjHM8ZQIgUdOT//4wtH 5R1cvrmcS9mO3rN9gR72oaelmJMvdqJ1DxaFiKgaqs3aCLmr/b9P+8k2fxGh4mSKJ5VD DdVoxDk504IuKcnX0c2CeozkUI3X57CE7bx08/kVfd4Ju6NAoNanv9bSQDCvDcRaenKc OWTVojrBinvVLtqQsymkuYf+uNlkTI5GQGvDNlq2og2rzmBBCk4LeDHOEXymwVKVifiM X53g== X-Gm-Message-State: ABUngvemnIeTNLYJ0gDOVYI0+9XwuLKwHnhozlnMjeb9x+2D45/1S2kVHGAG2znU/gTimuSuvZ2HqgQwGEwVZQ== X-Received: by 10.157.52.132 with SMTP id g4mr3020628otc.245.1477347349515; Mon, 24 Oct 2016 15:15:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.39 with HTTP; Mon, 24 Oct 2016 15:15:48 -0700 (PDT) In-Reply-To: References: <59C502F3-746D-47C8-8DF9-B4BC7A29FC70@jordanzimmerman.com> From: Cameron McKenzie Date: Tue, 25 Oct 2016 09:15:48 +1100 Message-ID: Subject: Re: PathChildrenCache : Accuracy To: user@curator.apache.org Content-Type: multipart/alternative; boundary=001a113ef7e4fa5273053fa3bb4e archived-at: Mon, 24 Oct 2016 22:16:04 -0000 --001a113ef7e4fa5273053fa3bb4e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You're absolutely correct, I just completely confused myself. Imesha, ignore my previous comment! cheers On Tue, Oct 25, 2016 at 3:43 AM, Jordan Zimmerman < jordan@jordanzimmerman.com> wrote: > PathChildrenCache was never intended to retain the order of events. In my > opinion, relying on order of events in a ZooKeeper-based application is a > design mistake. PathChildrenCache is designed to provide an eventually > consistent view of a ZNode=E2=80=99s children. > > Imesha, can you explain why you need to rely on event ordering? > > -Jordan > > On Oct 24, 2016, at 11:20 AM, Scott Blum wrote: > > Are you sure? I haven't dug deeply into PathChildrenCache but TreeCache > definitely does not work this way. The act of re-registering the watcher > is what fetches data. Let me amend your event list: > > -Watch children of /X > -Node /X/1 added > -TreeCache receives the ZK event for /X children changed > -Node /X/2 added (this event would be missed). > -TreeCache calls getChildren(/X) to re-register the watcher, sees both > /X/1 and /X/2 > -TreeCache publishes events for both /X/1 and /X/2 > > I looked at PathChildrenCache just a little and it looks like it might > work the same way. > > > IIRC, the kinds of events that might be missed are this: > > -Watch children of /X > -Node /X/1 added > -TreeCache receives the ZK event for /X children changed > -Node /X/2 added (this event would be missed). > -Node /X/2 deleted (this event would be missed). > -TreeCache calls getChildren(/X) to re-register the watcher, sees only /X= /1 > > In this case, TreeCache would never know about the existence of /X/2 sinc= e > it was created and deleted without the client being able to "see" it. Th= is > is a limitation in ZK's design. > > On Sun, Oct 23, 2016 at 10:44 PM, Cameron McKenzie > wrote: > >> Ordering should be consistent. There is always the possibility of missin= g >> a CHILD_CREATED event (or any other event), if it occurs in between the = ZK >> client being notified of an event and before the client has reregistered >> the watch. >> >> i.e. >> >> -Watch children of /X >> -Node /X/1 added >> -Client is notified of /X/1 child created event >> -Node /X/2 added (this event would be missed). >> -Client reregisters watch for children on /X >> >> >> On Mon, Oct 24, 2016 at 1:15 PM, Imesha Sudasingha < >> imesha.13@cse.mrt.ac.lk> wrote: >> >>> Thank you for the response. >>> >>> Yes, I'm aware of the conditions of an eventually consistent system. >>> What I wanted to know was, is there any possibility for the >>> PathChildrenCache to emit CHILD_CREATED like events out of order and wh= at >>> is the possibility of missing such event? >>> >>> Regards, >>> Imesha Sudasingha >>> >>> On Oct 21, 2016 7:12 PM, "Jordan Zimmerman" >>> wrote: >>> >>>> PathChildrenCache[1] is the solution you have provided to watch on a >>>> given node without using native zookeeper watchers. >>>> >>>> >>>> PathChildrenCache uses native watchers. Have a look at the source. >>>> >>>> Can anyone please clarify how the above effect can affect the accuracy >>>> of events listened? >>>> >>>> >>>> The point of that message is to remind you that ZooKeeper is an >>>> eventually consistent system. You are always seeing the view that the >>>> server you are connected to has. This is a feature of ZooKeeper, not >>>> Curator. >>>> >>>> Hope this helps. >>>> >>>> -Jordan >>>> >>>> On Oct 21, 2016, at 4:44 AM, Imesha Sudasingha >>>> wrote: >>>> >>>> Hi all, >>>> >>>> I have been using apache zookeeper. Now I'm willing to switch to >>>> CuratorFramework as it contains many useful recipes inbuilt. >>>> >>>> PathChildrenCache[1] is the solution you have provided to watch on a >>>> given node without using native zookeeper watchers. As I went through = the >>>> API [1] documentation, the following ambiguous sentence has caused me = to >>>> think twice as I want consistency accuracy for my implementation (such= as >>>> not missing CHILD_CREATED events). >>>> >>>> "it's not possible to stay transactionally in sync. Users of this >>>> class must be prepared for false-positives and false-negatives. >>>> Additionally, always use the version number when updating data to avoi= d >>>> overwriting another process' change." >>>> >>>> Can anyone please clarify how the above effect can affect the accuracy >>>> of events listened? And is there a way to w atch on a given node witho= ut >>>> using Zookeeper watchers and PathChildrenCache? >>>> >>>> (PathChildrenCache has the functionality I required. But the above >>>> description in the API docs matters me) >>>> >>>> Thanks in advance! >>>> >>>> [1] https://curator.apache.org/apidocs/org/apache/curator/fr >>>> amework/recipes/cache/PathChildrenCache.html >>>> >>>> Regards, >>>> Imesha Sudasingha >>>> >>>> -- >>>> *Imesha Sudasingha* >>>> Undergraduate of Department of Computer Science and Engineering, >>>> University of Moratuwa. >>>> +94717086160 >>>> View in Linkedin >>>> >>>> >>>> >> > > --001a113ef7e4fa5273053fa3bb4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're absolutely correct, I just completely confused = myself. Imesha, ignore my previous comment!
cheers

On Tue, Oct 25, 2016 at 3:= 43 AM, Jordan Zimmerman <jordan@jordanzimmerman.com> wrote:
PathChildrenCache was never intended to retain the order of events= . In my opinion, relying on order of events in a ZooKeeper-based applicatio= n is a design mistake. PathChildrenCache is designed to provide an eventual= ly consistent view of a ZNode=E2=80=99s children.

= Imesha, can you explain why you need to rely on event ordering?

-Jordan
<= /font>

On Oct 24, 2016, at 11:20 AM, Scott Blum <dragonsinth@gmail.com> wrote:
Are you sure?=C2=A0 I haven't dug deeply into PathChildrenCache b= ut TreeCache definitely does not work this way.=C2=A0 The act of re-registe= ring the watcher is what fetches data.=C2=A0 Let me amend your event list:<= div>
-Watch children of /X
-Node /X/1 added
-TreeCache receives the ZK event for /X children changed
-Node /X/2 added (this event would be miss= ed).
-TreeCache calls getChildren(/X) = to re-register the watcher, sees both /X/1 and /X/2
-TreeCache publishes events for both /X/1 and /X/2

I look= ed at PathChildrenCache just a little and it looks like it might work the s= ame way.


IIRC, the kind= s of events that might be missed are this:

-Watch children of /X
-Node /X/1 a= dded
-TreeCache receives the ZK event = for /X children changed
-Node /X/2 add= ed (this event would be missed).
-Node= /X/2 deleted (this event would be missed).
-TreeCache calls getChildren(/X) to re-register the watcher, sees onl= y /X/1

In this case, TreeCache would never know ab= out the existence of /X/2 since it was created and deleted without the clie= nt being able to "see" it.=C2=A0 This is a limitation in ZK's= design.

On Sun, Oct 23, 2016 at 10:44 PM, Cameron McKenzie <mckenzie= .cam@gmail.com> wrote:
Ordering should be consistent. There is always the possibility= of missing a CHILD_CREATED event (or any other event), if it occurs in bet= ween the ZK client being notified of an event and before the client has rer= egistered the watch.

i.e.

-Watc= h children of /X
-Node /X/1 added
-Client is notified o= f /X/1 child created event
-Node /X/2 added (this event would be = missed).
-Client reregisters watch for children on /X
<= br>

On Mon, Oct 24, 2016 at 1:15 PM, Imesha Sudasingha <imesha.13= @cse.mrt.ac.lk> wrote:

Thank you for the response.

Yes, I'm aware= of the conditions of an eventually consistent system. What I wanted to kno= w was, is there any possibility for the PathChildrenCache to emit CHILD_CRE= ATED like events out of order and what is the possibility of missing such e= vent?

Regards,
Imesha Sudasingha


On Oct 21, 2016 7= :12 PM, "Jordan Zimmerman" <jordan@jordanzimmerman.com> wrote:
PathChildrenCa= che[1] is the solution you have provided to watch on a given node without u= sing native zookeeper watchers.

PathChildrenCache uses native watchers. Have a look at the source.=C2=A0

Can= anyone please clarify how the above effect can affect the accuracy of even= ts listened?

The point of that messa= ge is to remind you that ZooKeeper is an eventually consistent system. You = are always seeing the view that the server you are connected to has. This i= s a feature of ZooKeeper, not Curator.

Hope this h= elps.

-Jordan

On Oct 21, 2016, at 4:44 AM, Imesha Sudasingha <imesha.13@cse.mrt.ac.lk&g= t; wrote:

Hi all,

I have been using apache zookeepe= r. Now I'm willing to switch to CuratorFramework as it contains many us= eful recipes inbuilt.=C2=A0

PathChildrenCache[1] i= s the solution you have provided to watch on a given node without using nat= ive zookeeper watchers. As I went through the API [1] documentation, the fo= llowing ambiguous sentence has caused me to think twice as I want consisten= cy accuracy for my implementation (such as not missing CHILD_CREATED events= ).

"it's not possible to stay transactionally in sync. = Users of this class must be prepared for false-positives and false-negative= s. Additionally, always use the version number when updating data to avoid = overwriting another process' change."

<= div>Can anyone please clarify how the above effect can affect the accuracy = of events listened? And is there a way to w atch on a given node without us= ing Zookeeper watchers and PathChildrenCache?

(Pat= hChildrenCache has the functionality I required. But the above description = in the API docs matters me)

Thanks in advance!


Regards,
Imesha Sudasingha

--
<= div dir=3D"ltr">
Imesha Sudasingha
Undergraduate of Department of Computer Sc= ience and =C2=A0Engineering,
University= of Moratuwa.
<= a href=3D"tel:%2B94717086160" value=3D"+94717086160" target=3D"_blank">+947= 17086160





--001a113ef7e4fa5273053fa3bb4e--