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
