[infinispan-dev] Changing default Hot Rod client max retries
mudokonman at gmail.com
Thu Jun 2 13:38:12 EDT 2016
On Wed, Jun 1, 2016 at 8:35 AM Dan Berindei <dan.berindei at gmail.com> wrote:
> I'd also like to see an option for the total time to wait, instead of
> having to worry about two (or more) different settings.
Only 1 config sounds good to me. I admit I am more used to total time to
wait rather than retry, using long and TimeUnit.
> True, if there's a bug that causes the request to fail immediately and
> the client retries without pause for 1 minute, it can generate a lot
> of unnecessary load. So perhaps we should only retry if we "know" the
> error can be fixed by retrying, e.g. on connection close or on
+1, retrying on specific exceptions sounds like a good idea to me
> On Wed, Jun 1, 2016 at 12:34 PM, Sanne Grinovero <sanne at infinispan.org>
> > No objection, just not sure about the usefulness. I think what matters
> > for people is how long is it going to wait before it fails.
> > If it's a long time (i.e. 10 minutes) then you'd probably want it try
> > faster than waiting 5 minutes for the second try ... exponential
> > backoff sounds nicer than trying to find a reasonable balance in the
> > connection retries.
> > Another benefit of an exponential backoff strategy is that you could
> > allow the users to set an option to wait essentially forever (until
> > interrupted: nicer to allow this control to higher up stacks), which
> > could be useful for cloud deployments, microservices, etc..
> > On 1 June 2016 at 09:26, Galder Zamarreño <galder at redhat.com> wrote:
> >> Hi all,
> >> Java Hot Rod client has 10 max retries as default. This sounds a bit
> too much, and as I find the need to add similar configuration to JS client,
> I'm wondering whether this should be reduce to 3 for all clients, including
> Java, C* and JS clients.
> >> Any objections?
> >> Cheers,
> >> --
> >> Galder Zamarreño
> >> Infinispan, Red Hat
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the infinispan-dev