Hi Jordan,
Thanks, I will raise JIRA with all the details.
On Friday, October 9, 2015 8:47 PM, Jordan Zimmerman
<[email protected]> wrote:
You are the first person to bring it up that I can recall in the many years of
Curator’s existence. If you want this feature you should open a Jira and try to
provide a pull request.
-JZ
On Oct 9, 2015, at 10:15 AM, pratap k <[email protected]> wrote:
Thanks, It will work !!Anything as long a different retry policy from
connection retry policy.
But, I just want to know how other 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.
