curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chao chu <chuchao...@gmail.com>
Subject Re: Using different Retry Policies for the same CuratorFramework instance
Date Mon, 08 Jul 2013 15:59:25 GMT
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