hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Spiewak <jspie...@gmail.com>
Subject Re: extensibility of DefaultHttpRequestRetryHandler
Date Mon, 11 Jun 2012 14:12:24 GMT
What about the scenario where a service is behind a load balancer?
In this case, one of two instances of the service is slow, and the load
balancer takes it out of service. A second request is required in order to
succeed, as opposed to just waiting twice as long.

I am not sure I understand your second paragraph. Are you saying that since
STE is a subclass of IOE, that you think an idempotent requests _should_ be
retried, or _should not_ be retried?

Given the current pattern of the code, having a set of classes representing
non-retry-able exceptions was what I was proposing, as opposed to the
positive case of a set of retry-able exceptions. What is the best way to
contribute a patch?


    -- Josh

On Sat, Jun 9, 2012 at 7:01 AM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Fri, 2012-06-08 at 10:32 -0400, Joshua Spiewak wrote:
> > The HttpClient tutorial uses socket timeout as an example of a
> recoverable
> > error in the introduction to Section 1.3 Exception Handling. However,
> > the DefaultHttpRequestRetryHandler will *not* retry when there is an
> > InterruptedIOException, e.g. a socket timeout.  Could someone share the
> > reasoning behind not retrying in this case? What is an example of a
> > sub-class of IOException that would be handled by
> > the DefaultHttpRequestRetryHandler? From looking at
> > TestDefaultHttpRequestRetryHandler, the only test case that expects a
> retry
> > is retryOnNonAbortedRequests, which use a straight IOException as the
> > exception to handle. There is no test case for SocketTimeoutException.
> >
> > I have internal applications that may experience a SocketTimeoutException
> > when there is a surge of requests, and in these circumstances I would
> like
> > to retry. I'd prefer not to copy the entire
> DefaultHttpRequestRetryHandler
> > class in order to allow for retries in this case.
> >
> > Would it make sense to have a Set<Class<IOException>>, by default
> > containing the enumerated exceptions, but is exposed to sub-classes that
> > can then add or remove entries?
> >
> > Or is there a better way of making DefaultHttpRequestRetryHandler
> > extensible?
> >
> > Thanks!
> >
> >     -- Josh
> Hi Josh
> It seems odd to me that one would want to retry requests on connect or
> socket timeouts N times effectively making timeout value N * T instead
> of T. One might as well set a higher timeout value from the beginning.
> SocketTimeoutException is a subclass of IOException, and I see no reason
> why it should be retried automatically by the
> DefaultHttpRequestRetryHandler as long as the request that caused it is
> idempotent.
> Having a set of classes that represent a recoverable condition sounds
> like a good idea to me. Please do feel free to contribute a better
> implementation of DefaultHttpRequestRetryHandler.
> Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message