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 274CCD0EA for ; Mon, 20 May 2013 19:21:01 +0000 (UTC) Received: (qmail 40176 invoked by uid 500); 20 May 2013 19:21:01 -0000 Delivered-To: apmail-curator-user-archive@curator.apache.org Received: (qmail 40133 invoked by uid 500); 20 May 2013 19:21:01 -0000 Mailing-List: contact user-help@curator.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.incubator.apache.org Delivered-To: mailing list user@curator.incubator.apache.org Received: (qmail 40118 invoked by uid 99); 20 May 2013 19:21:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 May 2013 19:21:00 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of iocanel@gmail.com designates 209.85.223.180 as permitted sender) Received: from [209.85.223.180] (HELO mail-ie0-f180.google.com) (209.85.223.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 May 2013 19:20:56 +0000 Received: by mail-ie0-f180.google.com with SMTP id ar20so14171917iec.25 for ; Mon, 20 May 2013 12:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=e8HdcbjS5VWQjJsmQY2ROpkfOtGkmFtvuY0e758QgoU=; b=BwTQpsnfR+QKPzOT6EKk+5vsqFs/Z1xYLa9BWauUilUg2rK4vmIPVlp70owwp9bj9S Urv+dMjHK8l4Ar88iD2YOG6oBDLNdBvSPdj71fPU+Pwb8UNNIUSBnwZUpnapRPHw1t58 v2ACguX3jDIqXc3cBXGf+b+YVpaAI3ys0Y0Vf2dglh3sJQJMI12JTY4qC4Zm0oDV4Cf+ QcQBuNgUisGi6zMBsP3ncKGdOJI98nmolreqpLwIrfC7CYbpoSYbmJVYorZw0FnnitZZ U5g/cw2GMnsTlk81uyrak8qOKQ3qaefUm6bRqmfcJTUG4634aJudIETk/NDwyRRqAHFA k7Wg== MIME-Version: 1.0 X-Received: by 10.50.60.41 with SMTP id e9mr5991070igr.94.1369077636002; Mon, 20 May 2013 12:20:36 -0700 (PDT) Received: by 10.50.25.136 with HTTP; Mon, 20 May 2013 12:20:35 -0700 (PDT) In-Reply-To: <0CD8689B-F263-4353-8599-6290DE1D4B13@jordanzimmerman.com> References: <32589246-CC39-42EA-AF3F-747458D9A32F@jordanzimmerman.com> <0CD8689B-F263-4353-8599-6290DE1D4B13@jordanzimmerman.com> Date: Mon, 20 May 2013 22:20:35 +0300 Message-ID: Subject: Re: ConnectionLoss and Retry Policy. From: Ioannis Canellos To: user@curator.incubator.apache.org Content-Type: multipart/alternative; boundary=047d7b10cea52a2aee04dd2b3ab0 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b10cea52a2aee04dd2b3ab0 Content-Type: text/plain; charset=ISO-8859-1 Thanks for clarifying. I had already read the tech note and this is why this started looking suspicious to me. Thanks again! On Mon, May 20, 2013 at 9:49 PM, Jordan Zimmerman < jordan@jordanzimmerman.com> wrote: > A few things: > > * Please read Curator Tech Note 1: > https://cwiki.apache.org/confluence/display/CURATOR/TN1 > > > i) Could it be caused by long running tasks triggered by a > ConnectionStateChangeListener? > Are the long running tasks run in Curator's listener thread? This would be > the same issue as TN1. > > >ii) If so, would it help if I passed an executor service along with the > listener or I should have the executor in the listener impl? > If you are going to execute tasks in response to listener events then, > yes, you should pass in an executor. > > -Jordan > > On May 20, 2013, at 11:46 AM, Ioannis Canellos wrote: > > Thanks for the quick response Jordan, > > Would it be possible to comment on i and ii please. Even if the root cause > doesn't lie there, I am curious if its a bad practice to go with (i) and if > I should prefer doing (ii). > > > On Mon, May 20, 2013 at 9:35 PM, Jordan Zimmerman < > jordan@jordanzimmerman.com> wrote: > >> There is a known issue with unstable clusters. It is fixed in >> 2.0.1-incubating: >> >> https://issues.apache.org/jira/browse/CURATOR-24 >> >> Please try building 2.0.1 and see how it goes (there will be an official >> release of it soon). >> >> -Jordan >> >> On May 20, 2013, at 5:24 AM, Ioannis Canellos wrote: >> >> I am using curator version 2.0.0-incubating and even though I am using a >> retry policy (usually something like 10 retries with 1 sec delay), I am not >> always successfully recovering from a connection loss. >> >> In many cases I do see the RECONNECTED state change in my logs right >> after the retry policy has been exhausted and this makes me think that its >> possible that something is blocking the event while retrying. >> >> Questions: >> i) Could it be caused by long running tasks triggered by a >> ConnectionStateChangeListener? >> ii) If so, would it help if I passed an executor service along with the >> listener or I should have the executor in the listener impl? >> iii) Other ideas? >> >> -- >> *Ioannis Canellos* >> * >> >> ** >> Blog: http://iocanel.blogspot.com >> **Twitter: iocanel* >> >> >> > > > -- > *Ioannis Canellos* > * > > ** > Blog: http://iocanel.blogspot.com > **Twitter: iocanel* > > > -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel * --047d7b10cea52a2aee04dd2b3ab0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for clarifying.

I had alre= ady read the tech note and this is why this started looking suspicious to m= e.

Thanks again!


On Mon, May 20, 2013 at 9:49 PM, Jordan = Zimmerman <jordan@jordanzimmerman.com> wrote:
A few things:

=

> i) Could it be caused by long ru= nning tasks triggered by a ConnectionStateChangeListener?
A= re the long running tasks run in Curator's listener thread? This would = be the same issue as TN1.

>ii) If so, would it help if I pas= sed an executor service along with the listener or I should have the execut= or in the listener impl?
If you are going to execute tasks in resp= onse to listener events then, yes, you should pass in an executor.

-Jordan<= /div>

On May 20, 2013, at= 11:46 AM, Ioannis Canellos <iocanel@gmail.com> wrote:

Thanks for the quick respons= e Jordan,

Would it be possible to comment on i and ii pl= ease. Even if the root cause doesn't lie there, I am curious if its a b= ad practice to go with (i) and if I should prefer doing (ii).


On Mon,= May 20, 2013 at 9:35 PM, Jordan Zimmerman <jordan@jordanzimmerma= n.com> wrote:
There is a known issue= with unstable clusters. It is fixed in 2.0.1-incubating:


Please try b= uilding 2.0.1 and see how it goes (there will be an official release of it = soon).

-Jordan

On May 20, 2013, at 5:24 AM, Ioannis Canellos <= ;iocanel@gmail.com> wrote:





--
Ioannis Canellos

Blog:=A0http://iocanel.blogspot.comTwitter: iocanel





--
Ioannis Canellos

Blog:=A0http://iocanel.blogspot.com
Twitter: iocanel
=

--047d7b10cea52a2aee04dd2b3ab0--