Return-Path: 
 <user-return-804-apmail-curator-user-archive=curator.apache.org@curator.apache.org>
X-Original-To: apmail-curator-user-archive@minotaur.apache.org
Delivered-To: apmail-curator-user-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 795EF17E29
	for <apmail-curator-user-archive@minotaur.apache.org>;
 Mon,  3 Nov 2014 15:02:39 +0000 (UTC)
Received: (qmail 10588 invoked by uid 500); 3 Nov 2014 15:02:39 -0000
Delivered-To: apmail-curator-user-archive@curator.apache.org
Received: (qmail 10547 invoked by uid 500); 3 Nov 2014 15:02:39 -0000
Mailing-List: contact user-help@curator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:user-help@curator.apache.org>
List-Unsubscribe: <mailto:user-unsubscribe@curator.apache.org>
List-Post: <mailto:user@curator.apache.org>
List-Id: <user.curator.apache.org>
Reply-To: user@curator.apache.org
Delivered-To: mailing list user@curator.apache.org
Received: (qmail 10537 invoked by uid 99); 3 Nov 2014 15:02:39 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Nov 2014 15:02:39 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [209.85.213.181] (HELO mail-ig0-f181.google.com)
 (209.85.213.181)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Nov 2014 15:02:12 +0000
Received: by mail-ig0-f181.google.com with SMTP id l13so5115241iga.14
        for <user@curator.apache.org>; Mon, 03 Nov 2014 07:00:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:date:from:to:message-id:in-reply-to:references
         :subject:mime-version:content-type;
        bh=Ocxy+0Mr2VecINsg23dPD8zlFLNpB5BzPlWfCTLZUhU=;
        b=XrdIaqDCT1YMurK/y07yadCsBypyWf4JSg6dSxq2qFZLxhDGUtwLvDR4wGYM5BydaD
         5BgZOk7kkm1DCEw1iDKNrW3JefJI8Qyqa9lxt3g/Ldhdm30W7NP/MA7Orx10VxKOEQg9
         JOUkQLf+xABEFVQVK/xlRtyoXkx6OyQqOn0ZaWbX9HUzloQizq5hdo7l/5HcTebpL7ae
         5cXpCMIlJOxPpcql32IY7rBBAISO8QMlPA7hfhDnOihr1MVmjGoOzgx92WQCBMKEDsw1
         9kEaDo1COgD8+j0ktZRyNztxUvsqETFniexhiLyaXow5FjK8ib+wyYhHOQfok56330cR
         S8xQ==
X-Gm-Message-State: 
 ALoCoQnC4DaXC0mQrjEaYQH8HNRzlVBBGVvZSrRJlFkgrL7R4vXPQd5MDhRMQeE72/+Xu3Jk4ibG
X-Received: by 10.42.169.72 with SMTP id a8mr41080537icz.47.1415026825510;
        Mon, 03 Nov 2014 07:00:25 -0800 (PST)
Received: from Jordans-MacBook-Pro.local ([190.141.38.38])
        by mx.google.com with ESMTPSA id
 a192sm9388329ioa.34.2014.11.03.07.00.24
        for <multiple recipients>
        (version=SSLv3 cipher=RC4-SHA bits=128/128);
        Mon, 03 Nov 2014 07:00:25 -0800 (PST)
Date: Mon, 3 Nov 2014 10:00:22 -0500
From: Jordan Zimmerman <jordan@jordanzimmerman.com>
To: Tony Jackson <tjacksonfr@mail.com>, user@curator.apache.org
Message-ID: <etPan.54579886.6b8b4567.2f25@Jordans-MacBook-Pro.local>
In-Reply-To: 
 <trinity-e0a6db37-8910-48f7-920a-ba9bee8943aa-1414993255529@3capp-mailcom-lxa04>
References: 
 <trinity-cd834f31-43ab-4a23-a07a-184a6b7a0dfb-1414991047387@3capp-mailcom-lxa04>
 <CANykduZhMH=Az1SbHEWF=Z+GSvT=+at63_RYkU1q6ZdX+MoCsQ@mail.gmail.com>
 <trinity-e0a6db37-8910-48f7-920a-ba9bee8943aa-1414993255529@3capp-mailcom-lxa04>
Subject: Re: Watcher latency question
X-Mailer: Airmail (249)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="54579886_327b23c6_2f25"
X-Virus-Checked: Checked by ClamAV on apache.org

--54579886_327b23c6_2f25
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

You know, Curator has the ServiceDiscovery recipe that already does what =
you describe.

-Jordan


On November 3, 2014 at 12:41:34 AM, Tony Jackson (tjacksonfr=40mail.com) =
wrote:

I have a client (or several clients responsible for different services) w=
atching a particular znode, and will notify other services that newly reg=
istered machines are available now. The registered machines may be up to =
e.g. 4k=7E5k. So effect like diff would be preferred if possible. Otherwi=
se clients responsible for watching znodes need to cache and diff by itse=
lf. That seems to be an overhead for clients because it needs to hold man=
y information related to the registered nodes and perform diff function w=
ith old one. =20

However I am naive about this, so I appreciate any advises. =20

Thanks=C2=A0 =20
=C2=A0 =20

>Sent:=C2=A0Monday, November 03, 2014 at 1:11 PM =20
>=46rom:=C2=A0=22Cameron McKenzie=22 <mckenzie.cam=40gmail.com> =20
>To:=C2=A0user=40curator.apache.org =20
>Subject:=C2=A0Re: Watcher latency question =20

>hey Tony, =20
>The way that watches work in ZK is that once they fire they need to be a=
dded back again. If the data >in ZK changes before the watch is reset, th=
en the client will not find out about this change in data. =20
=C2=A0 =20
>i.e You're watching the data in node /test =20
>-Data changes to state 'A' =20
>-Watch fires =20
>-Data changes to state 'B' =20
>-Data changes to state 'A' =20
>-Reset watch =20
>-Data changes to state 'C' =20
>-Watch fires =20
=C2=A0 =20
>You're going to miss the intermediate state where the data transitioned =
from state A to state B and >back to state A again. This is just a limita=
tion of ZK, there's a window of opportunity for these >events to be misse=
d. I don't think that the PathCache in Curator is going to solve this pro=
blem. =20
=C2=A0 =20
>Do you have a particular use case where missing these transitions is an =
issue=3F =20
=C2=A0 =20
>cheers =20
>Cam =20
=C2=A0 =20
>>On Mon, Nov 3, 2014 at 4:04 PM, Tony Jackson <tjacksonfr=40mail.com> wr=
ote:I read some articles mentioning that Zookeeper watcher has latency is=
sue. Something like before the next watcher is placed and after the previ=
ous watcher is triggered, it is possible that the client may not receive =
notification within that period. =20
=C2=A0 =20
>>http://www.quora.com/Does-Zookeeper-clients-keep-open-lots-of-TCP-conne=
ctions-if-so-how-scalable-is-it-Any-limits=5Bhttp://www.quora.com/Does-Zo=
okeeper-clients-keep-open-lots-of-TCP-connections-if-so-how-scalable-is-i=
t-Any-limits=5D =20
=C2=A0 =20
>>Then on the internet some people recommend using curator pathcache, whi=
ch helps watch child znodes being added, updated, etc. operations. So my =
question - is it the right recipe to use if I want to avoid watcher laten=
cy problem=3F Otherwise which recipe should I use instead or how to avoid=
 such problem with curator=3F =20
=C2=A0 =20
>>http://curator.apache.org/curator-recipes/path-cache.html=5Bhttp://cura=
tor.apache.org/curator-recipes/path-cache.html=5D =20
=C2=A0 =20
>>Thanks =20

--54579886_327b23c6_2f25
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</=
style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust=
omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r=
gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>You know, Curator has =
the ServiceDiscovery recipe that already does what you describe.</div><di=
v id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;fo=
nt-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>=
<br></div><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helve=
tica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-heig=
ht: auto;=22>-Jordan</div> <div id=3D=22bloop=5Fsign=5F141502679351174681=
6=22 class=3D=22bloop=5Fsign=22><div style=3D=22font-family:helvetica,ari=
al;font-size:13px=22><br></div></div> <br><p style=3D=22color:=23000;=22>=
On November 3, 2014 at 12:41:34 AM, Tony Jackson (<a href=3D=22mailto:tja=
cksonfr=40mail.com=22>tjacksonfr=40mail.com</a>) wrote:</p> <blockquote t=
ype=3D=22cite=22 class=3D=22clean=5Fbq=22><span><div><div></div><div>I ha=
ve a client (or several clients responsible for different services) watch=
ing a particular znode, and will notify other services that newly registe=
red machines are available now. The registered machines may be up to e.g.=
 4k=7E5k. So effect like diff would be preferred if possible. Otherwise c=
lients responsible for watching znodes need to cache and diff by itself. =
That seems to be an overhead for clients because it needs to hold many in=
formation related to the registered nodes and perform diff function with =
old one. =20
<br>
<br>However I am naive about this, so I appreciate any advises.  =20
<br>
<br>Thanks&nbsp;
<br>&nbsp;
<br>
<br>&gt;Sent:&nbsp;Monday, November 03, 2014 at 1:11 PM
<br>&gt;=46rom:&nbsp;=22Cameron McKenzie=22 &lt;mckenzie.cam=40gmail.com&=
gt;
<br>&gt;To:&nbsp;user=40curator.apache.org
<br>&gt;Subject:&nbsp;Re: Watcher latency question
<br>
<br>&gt;hey Tony,
<br>&gt;The way that watches work in ZK is that once they fire they need =
to be added back again. If the data &gt;in ZK changes before the watch is=
 reset, then the client will not find out about this change in data.
<br>&nbsp;
<br>&gt;i.e You're watching the data in node /test
<br>&gt;-Data changes to state 'A'
<br>&gt;-Watch fires
<br>&gt;-Data changes to state 'B'
<br>&gt;-Data changes to state 'A'
<br>&gt;-Reset watch
<br>&gt;-Data changes to state 'C'
<br>&gt;-Watch fires
<br>&nbsp;
<br>&gt;You're going to miss the intermediate state where the data transi=
tioned from state A to state B and &gt;back to state A again. This is jus=
t a limitation of ZK, there's a window of opportunity for these &gt;event=
s to be missed. I don't think that the PathCache in Curator is going to s=
olve this problem.
<br>&nbsp;
<br>&gt;Do you have a particular use case where missing these transitions=
 is an issue=3F
<br>&nbsp;
<br>&gt;cheers
<br>&gt;Cam
<br>&nbsp;
<br>&gt;&gt;On Mon, Nov 3, 2014 at 4:04 PM, Tony Jackson &lt;tjacksonfr=40=
mail.com&gt; wrote:I read some articles mentioning that Zookeeper watcher=
 has latency issue. Something like before the next watcher is placed and =
after the previous watcher is triggered, it is possible that the client m=
ay not receive notification within that period.
<br>&nbsp;
<br>&gt;&gt;http://www.quora.com/Does-Zookeeper-clients-keep-open-lots-of=
-TCP-connections-if-so-how-scalable-is-it-Any-limits=5Bhttp://www.quora.c=
om/Does-Zookeeper-clients-keep-open-lots-of-TCP-connections-if-so-how-sca=
lable-is-it-Any-limits=5D
<br>&nbsp;
<br>&gt;&gt;Then on the internet some people recommend using curator path=
cache, which helps watch child znodes being added, updated, etc. operatio=
ns. So my question - is it the right recipe to use if I want to avoid wat=
cher latency problem=3F Otherwise which recipe should I use instead or ho=
w to avoid such problem with curator=3F
<br>&nbsp;
<br>&gt;&gt;http://curator.apache.org/curator-recipes/path-cache.html=5Bh=
ttp://curator.apache.org/curator-recipes/path-cache.html=5D
<br>&nbsp;
<br>&gt;&gt;Thanks
<br></div></div></span></blockquote></body></html>
--54579886_327b23c6_2f25--