curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: question about curator - retry policy
Date Fri, 20 May 2016 21:10:37 GMT
Curator’s retry policies are used within each CuratorFramework operation. For example, when
you call client.setData().forPath(p, b) the retry policy will be invoked if there is a retry-able
exception during the operation. In addition to the retryPolicy, there are connection timeouts.
The behavior of how this is handled changed between Curator 2.x and Curator 3.x. In Curator
2.x, for every iteration of the retry, the operation will wait until connection timeout when
there’s no connection. In Curator 3.x, the connection timeout wait only occurs once (if
the default ConnectionHandlingPolicy is used).

In any event, ZooKeeper itself tries to maintain the connection. Also, Curator will re-create
the internally managed connection depending various network interruptions, etc. I’d need
to see the logs to give you more input. 

-Jordan

> On May 19, 2016, at 10:12 AM, Moshiko Kasirer <moshek@liveperson.com> wrote:
> 
> first i would like to thank you about curator we are using it as part of our service
discovery 
> 
> solution and it helps a lot!! 
> 
> i have a question i hope you will be able to help me with. 
> 
> its regarding the curator retry policy it seems to me we dont really understand when
this policy is 
> 
> invoked,  as i see in our logs that although i configured it as max retry 1 actually
in the logs i see 
> 
> many ZK re connection attempts (and many curator gave up messages but later i see 
> 
> reconnected status...) . is it possible that that policy is only relevant to manually
invoked 
> 
> operations against the ZK cluster done via curator ? and that the re connections i see
in the logs 
> 
> are caused by the fact that the ZK was available during start up so sessions were created
and 
> 
> then when ZK was down the ZK clients (not curator)  are sending heartbeats as part of
the ZK 
> 
> architecture? that is the part i am failing to understand and i hope you can help me
with that.
> 
> you have recently added RetreyAllways policy and i wanted to know if it is save to use
it? 
> 
> the thing is we always want to retry to reconnect to ZK when he is available but that
is something 
> 
> the ZK client does as long as he has open sessions right?  i am not sure that it has
to do with the 
> 
> retry policy ... 
> 
> thanks,
> 
> moshiko
> 
> -- 
> 
> Moshiko Kasirer
> Software Engineer
> T: +972-74-700-4357
>  <http://www.linkedin.com/company/164748>	 <http://twitter.com/liveperson>
 <http://www.facebook.com/LivePersonInc>	We Create Meaningful Connections
>  <http://roia.biz/im/n/ndiXvq1BAAGhL0MAABW7QgABwExmMQA-A/>
> 
> This message may contain confidential and/or privileged information. 
> If you are not the addressee or authorized to receive this on behalf of the addressee
you must not use, copy, disclose or take action based on this message or any information herein.

> If you have received this message in error, please advise the sender immediately by reply
email and delete this message. Thank you.


Mime
View raw message