Return-Path: 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 048A810EDB for ; Thu, 14 Nov 2013 07:26:18 +0000 (UTC) Received: (qmail 72617 invoked by uid 500); 14 Nov 2013 07:26:15 -0000 Delivered-To: apmail-curator-user-archive@curator.apache.org Received: (qmail 72587 invoked by uid 500); 14 Nov 2013 07:26:13 -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 72573 invoked by uid 99); 14 Nov 2013 07:26:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Nov 2013 07:26:11 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of shaun.senecal@mail.rakuten.com designates 213.199.154.189 as permitted sender) Received: from [213.199.154.189] (HELO db8outboundpool.messaging.microsoft.com) (213.199.154.189) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Nov 2013 07:26:04 +0000 Received: from mail178-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE013.bigfish.com (10.174.4.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 07:25:42 +0000 Received: from mail178-db8 (localhost [127.0.0.1]) by mail178-db8-R.bigfish.com (Postfix) with ESMTP id 3CA3234015F for ; Thu, 14 Nov 2013 07:25:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:111.221.116.165;KIP:(null);UIP:(null);IPV:NLI;H:SIXPRD0310HT002.apcprd03.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(z579eh27d3lz98dI9371Ic85dh4015Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h1155h) Received-SPF: pass (mail178-db8: domain of mail.rakuten.com designates 111.221.116.165 as permitted sender) client-ip=111.221.116.165; envelope-from=shaun.senecal@mail.rakuten.com; helo=SIXPRD0310HT002.apcprd03.prod.outlook.com ;.outlook.com ; Received: from mail178-db8 (localhost.localdomain [127.0.0.1]) by mail178-db8 (MessageSwitch) id 1384413939825092_4075; Thu, 14 Nov 2013 07:25:39 +0000 (UTC) Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.240]) by mail178-db8.bigfish.com (Postfix) with ESMTP id BB41C5C0040 for ; Thu, 14 Nov 2013 07:25:39 +0000 (UTC) Received: from SIXPRD0310HT002.apcprd03.prod.outlook.com (111.221.116.165) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 07:25:39 +0000 Received: from SIXPRD0310MB360.apcprd03.prod.outlook.com ([169.254.3.190]) by SIXPRD0310HT002.apcprd03.prod.outlook.com ([10.255.22.165]) with mapi id 14.16.0371.000; Thu, 14 Nov 2013 07:25:34 +0000 From: "Senecal, Shaun | Shaun | BDD" To: "user@curator.apache.org" Subject: RE: how to properly recreate ephemeral nodes and reset watches after a session expiry Thread-Topic: how to properly recreate ephemeral nodes and reset watches after a session expiry Thread-Index: Ac7fbnkxO4TsRmh2RYmkSNgCsNUvAwAS7+aAAFKYlpcAATnVAAAAM6lD Date: Thu, 14 Nov 2013 07:25:34 +0000 Message-ID: References: <02D794A8-50BD-42D9-9AC2-D1AA5E764FBD@jordanzimmerman.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.72.49.236] Content-Type: multipart/alternative; boundary="_000_EB75668D48CD564CB2B9A4007534C91C4D456042SIXPRD0310MB360_" MIME-Version: 1.0 X-OriginatorOrg: mail.rakuten.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Checked: Checked by ClamAV on apache.org --_000_EB75668D48CD564CB2B9A4007534C91C4D456042SIXPRD0310MB360_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't see any references to ConnectionStateListener or ConnectionState.RE= CONNECTED in PersistentEphemeralNode. How does it know when the connection= state is changed to RECONNECTED? ________________________________ From: Bae, Jae Hyeon [metacret@gmail.com] Sent: Thursday, November 14, 2013 4:17 PM To: user@curator.apache.org Subject: Re: how to properly recreate ephemeral nodes and reset watches aft= er a session expiry When the connection state is changed to RECONNECTED, PersistentEphemeralNod= e is retrying to create the node and set the watcher. On Wed, Nov 13, 2013 at 10:47 PM, Senecal, Shaun | Shaun | BDD > wrote: How does this work if the connection to ZK is lost for an extended period o= f time? Depending on your retry behaviour, it appears to give up retrying = before the connection is re-established and the watch isn't set. I can't s= ee how PersistentEphemeralNode is handling this situation, is there some tr= ick I am missing? Shaun ________________________________ From: Jordan Zimmerman [jordan@jordanzimmerman.com] Sent: Wednesday, November 13, 2013 12:16 AM To: user@curator.apache.org Subject: Re: how to properly recreate ephemeral nodes and reset watches aft= er a session expiry Have a look at PersistentEphemeralNode. It does this. -Jordan On Nov 11, 2013, at 11:20 PM, Senecal, Shaun | Shaun | BDD > wrote: Hi, I have some code that needs to be able to recreate ephemeral nodes and rese= t watches after a session expiry. The approach currently taken is to keep = track of all nodes that need to be recreated and all watches that need to b= e reset, then use a ConnectionStateListener to trigger the recovery process= when a RECONNECTED event is received after a LOST event. It has been a pa= inful process getting this to work, because I want the logic to be able to = survive issues that occur DURING the recovery process as well. While the current implementation seems to be working, I'm left feeling that= there has to be a better way to do this. What is the "best practice" appr= oach? I came across this link (https://listserv.netflix.com/pipermail/curator-use= rs/2012-June/000068.html) implying that you shouldn't recreate ephemeral no= des in a ConnectionStateListener, and instead should add a watch to each no= de which recreates the node when NodeDeleted or Expired is received. I hav= e tested this solution and it appears to work. The only place I see this m= ethod getting really complicated is if I need to set watches (ie getData())= on ephemeral nodes which I want to be reset after an expiry since I would = need to worry about ensuring the ephemeral node is recreated before attempt= ing to reset the watch. Is this considered the best practice? Thanks, Shaun --_000_EB75668D48CD564CB2B9A4007534C91C4D456042SIXPRD0310MB360_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't see any references to ConnectionStateListener or ConnectionS= tate.RECONNECTED in PersistentEphemeralNode.  How does it know when th= e connection state is changed to RECONNECTED?


From: Bae, Jae Hyeon [metacret@gmail.com]=
Sent: Thursday, November 14, 2013 4:17 PM
To: user@curator.apache.org
Subject: Re: how to properly recreate ephemeral nodes and reset watc= hes after a session expiry

When the connection state is changed to RECONNECTED, Persi= stentEphemeralNode is retrying to create the node and set the watcher.


On Wed, Nov 13, 2013 at 10:47 PM, Senecal, Shaun= | Shaun | BDD <shaun.senecal@mail.rakuten.com> wrote:
How does t= his work if the connection to ZK is lost for an extended period of time?&nb= sp; Depending on your retry behaviour, it appears to give up retrying befor= e the connection is re-established and the watch isn't set.  I can't see how PersistentEphemeralNode is hand= ling this situation, is there some trick I am missing?


Shaun

Fro= m: Jordan Zimmerman [jordan@jordanzimmerman.com]
Sent: Wednesday, November 13, 2013 12:16 AM
To: use= r@curator.apache.org
Subject: Re: how to properly recreate ephemeral nodes and reset watc= hes after a session expiry

Have a look at PersistentEphemeralNode. It does this.

-Jordan

On Nov 11, 2013, at 11:20 PM, Senecal, Shaun | Shaun | BDD <shaun.senecal@= mail.rakuten.com> wrote:

Hi,

I have some code that needs to be able to recreate ephemeral nodes and rese= t watches after a session expiry.  The approach currently taken is to = keep track of all nodes that need to be recreated and all watches that need= to be reset, then use a ConnectionStateListener to trigger the recovery process when a RECONNECTED event is received after= a LOST event.  It has been a painful process getting this to work, be= cause I want the logic to be able to survive issues that occur DURING the r= ecovery process as well.

While the current implementation seems to be working, I'm left feeling that= there has to be a better way to do this.  What is the "best prac= tice" approach?

I came across this link (https://listserv.net= flix.com/pipermail/curator-users/2012-June/000068.html) implying that y= ou shouldn't recreate ephemeral nodes in a ConnectionStateListener, and instead should add a watch to each node = which recreates the node when NodeDeleted or Expired is received.  I h= ave tested this solution and it appears to work.  The only place I see= this method getting really complicated is if I need to set watches (ie getData()) on ephemeral nodes which I want to= be reset after an expiry since I would need to worry about ensuring the ep= hemeral node is recreated before attempting to reset the watch.  Is th= is considered the best practice?



Thanks,

Shaun


--_000_EB75668D48CD564CB2B9A4007534C91C4D456042SIXPRD0310MB360_--