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 < [email protected]> 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 <[email protected]> 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 *
