So, in this case use setRetryPolicy for your initial call and then change it afterward.
-JZ On Jul 10, 2013, at 10:26 AM, chao chu <[email protected]> wrote: > Yep, since in our environment, the zk ensemble is managed by another infra > team and it's a shared infrastructure resources. It happened before that the > zk servers become unavailable for like 30 mins. > > For now, we have no control for that, so we need to code very defensively. > > > On Tue, Jul 9, 2013 at 1:16 AM, Jordan Zimmerman <[email protected]> > wrote: > Do you expect ZooKeeper to be unresponsive for some reason? Retry is only > needed when the ZooKeeper connection has issues. > -JZ > > > On Jul 8, 2013, at 8:59 AM, chao chu <[email protected]> wrote: > >> for example, in our case, we will read all the global configuration info at >> the startup time, we want to use a RetryNTimes with a relative large n. >> >> and during the running of the app, we also will read some app local config, >> and I am thinking about using a ExponentialBackoffRetry with a smaller n. >> >> Does this make sense? >> >> >> >> >> On Mon, Jul 8, 2013 at 11:36 PM, Jordan Zimmerman >> <[email protected]> wrote: >> Can you explain why you want different retry policies for different >> operations? >> >> > Is it normal to change the underlying CuratorZooKeeperClient's retry >> > policy via the setter to achieve this? >> No. Changing the retry policy changes it for all users in all threads. >> >> -JZ >> >> On Jul 8, 2013, at 7:57 AM, chao chu <[email protected]> wrote: >> >> > Hi, >> > >> > The constructor/factory method to create a CuratorFramework instance need >> > a 'retry policy'. However, in our case, we may need to use different retry >> > policies for different operations. >> > >> > Is it normal to change the underlying CuratorZooKeeperClient's retry >> > policy via the setter to achieve this? >> > >> > Thanks & Regards, >> > >> > -- >> > ChuChao >> >> >> >> >> -- >> ChuChao > > > > > -- > ChuChao
