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] > <mailto:[email protected]>> wrote: > I couldn't find withRetryPolicy > https://www.google.co.in/search?q=withRetryPolicy+curatorframework > <https://www.google.co.in/search?q=withRetryPolicy+curatorframework> > https://github.com/apache/curator/search?utf8=%E2%9C%93&q=withRetryPolicy > <https://github.com/apache/curator/search?utf8=%E2%9C%93&q=withRetryPolicy> > > > On Friday, October 9, 2015 8:16 PM, Jordan Zimmerman > <[email protected] <mailto:[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] >> <mailto:[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. >> > > > > > > >
