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
