Yes, sorry. This would have to be added. -JZ
> On Oct 9, 2015, at 10:08 AM, 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. >> > > > > >
