curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <ioca...@gmail.com>
Subject Re: ConnectionLoss and Retry Policy.
Date Mon, 20 May 2013 19:20:35 GMT
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 <iocanel@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 <iocanel@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
*

Mime
View raw message