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
<[email protected]> 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 <[email protected]> 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
<[email protected]> wrote:
Perform the operations in the background. E.g.
client.create().inBackground().forPath(p);
On Oct 9, 2015, at 6:23 AM, pratap k <[email protected]> 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
