curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Using different Retry Policies for the same CuratorFramework instance
Date Mon, 08 Jul 2013 17:16:21 GMT
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 <chuchao333@gmail.com> 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 <jordan@jordanzimmerman.com>
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 <chuchao333@gmail.com> 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


Mime
View raw message