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] >> <mailto:[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 >> >> > > >
