curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From pratap k <pratap_...@yahoo.com>
Subject Re: Curator Method calls are blocking when zookeeper is down
Date Fri, 09 Oct 2015 14:44:14 GMT
I meant for zookeeper API methods there should be a different retry policy, not that I don't
want any retry.For ex: After successful startup, If the zookeeper is down for 2 days, and
then your application calls the Zookeeper API, It is simply blocked. 

>>  Don’t call exists() if the state isn’t CONNECTED/RECONNECTED. 
Yes, this will work, I did thought the same, but then I have to put this boiler plate code
everywhere. It is better if things are handled at curator side.
>> You could even write a custom retry policy that does this internally.I am not sure
if the retry policy method will be invoked with a different parameter to say it is for method
call.I will check this though. 

>> Another possibility is to have a 2nd Curator instance with a different retry policyBut,
that will create another Zookeeper session/connection, and that can cause problem with ephimeral
nodes.
>> Lastly, we could add a method to change the retry policy.That would be great, but
only if doesn't change connection retry policy.
As said, better to have one retry policy for connection retry, and other for application threads
Zookeeper API calls.


Regards,Pratap


 



     On Friday, October 9, 2015 8:03 PM, Jordan Zimmerman <jordan@jordanzimmerman.com>
wrote:
   

 I don’t understand your need. Any ZooKeeper API call requires a connection. Are you saying
you don’t want to retry on certain calls? Add a Connection State listener and keep track
of the state. Don’t call exists() if the state isn’t CONNECTED/RECONNECTED. You could
even write a custom retry policy that does this internally. Another possibility is to have
a 2nd Curator instance with a different retry policy. Lastly, we could add a method to change
the retry policy.
-JZ

On Oct 9, 2015, at 9:27 AM, pratap k <pratap_sms@yahoo.com> wrote:
 Hi Jordan,
We don't want asynchronous calls, as we need immediately what is the result of the operation.Basically,
I am looking for the method calls ( like checkExists)  to return immediately or have a different
retry policy other than connection retry.

Basically, by using same retry policy for connection retry and the method retry, the application
threads are getting impacted with the connection retry policy. For ex: if  Exponentional
Backoff policy is mentioned, there is a chance of method call being blocked indefinately if
zookeeper server goes down. 



Regards,Pratap 


     On Friday, October 9, 2015 5:46 PM, Jordan Zimmerman <jordan@jordanzimmerman.com>
wrote:
   

 Perform the operations in the background. E.g.
client.create().inBackground().forPath(p);

On Oct 9, 2015, at 6:23 AM, pratap k <pratap_sms@yahoo.com> wrote:
Hi All,
We are using Curator Framework with exponential backoff retry policy, assuming that the retry
policy is specific to connection retry logic. But, when the zookeeper is down, the transaction
method calls ( like create, getData, create) are blocking. 
CuratorFrameworkFactory.newClient(zookeeperConnectionString, retryPolicy)

We don't want to block the application threads when the zookeeper is not available, But don't
want to change the connection retry policy.
Is there anyway we can do this ?
Regards,Pratap






   



  
Mime
View raw message