You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by Ioannis Canellos <io...@gmail.com> on 2013/05/20 14:24:51 UTC
ConnectionLoss and Retry Policy.
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
*
Re: ConnectionLoss and Retry Policy.
Posted by Ioannis Canellos <io...@gmail.com>.
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 <io...@gmail.com> 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 <io...@gmail.com> 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
*
Re: ConnectionLoss and Retry Policy.
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <io...@gmail.com> 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 <jo...@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 <io...@gmail.com> 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
>
Re: ConnectionLoss and Retry Policy.
Posted by Ioannis Canellos <io...@gmail.com>.
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 <io...@gmail.com> 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
*
Re: ConnectionLoss and Retry Policy.
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 <io...@gmail.com> 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
>