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 18:46:01 GMT
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
*

Mime
View raw message