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
