Thanks, It will work !!Anything as long a different retry policy accepted
other than connection retry policy. It would be great to have one global retry
policy for Zookeeper API retry.
But, I just want to know how others are building their application, it is a big
issue as it will impact resilience of web apps.
Regards,Pratap
On Friday, October 9, 2015 8:39 PM, Mike Drob <[email protected]> wrote:
I think Jordan was presenting that as a possible API and asking if that would
meet your needs.
On Fri, Oct 9, 2015 at 10:07 AM, pratap k <[email protected]> wrote:
I couldn't find withRetryPolicy
https://www.google.co.in/search?q=withRetryPolicy+curatorframework
https://github.com/apache/curator/search?utf8=%E2%9C%93&q=withRetryPolicy
On Friday, October 9, 2015 8:16 PM, Jordan Zimmerman
<[email protected]> wrote:
CuratorFramework.withRetryPolicy() - it would be the same Curator connection
but with a different retry policy. Similar to CuratorFramework.withNamespace().
-JZ
On Oct 9, 2015, at 9:44 AM, pratap k <[email protected]> wrote:
>> 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.
