curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Curator Method calls are blocking when zookeeper is down
Date Fri, 09 Oct 2015 14:33:02 GMT
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 <mailto: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