On Mon, Jun 11, 2012 at 11:28 AM, Oleg Kalnichevski <[email protected]>wrote:
> On Mon, 2012-06-11 at 10:12 -0400, Joshua Spiewak wrote:
> > 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?
> >
>
> Excuse my being such a mess. Yes, I meant to say SocketExceptions were
> expected to be retried automatically provided other conditions (such as
> request idempotency) were satisfied.
>
>
No problem. But back to my original point, SocketTimeoutException extends
InterruptedIOException, and that is explicitly not retried. So is that a
bug?
> > 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?
> >
>
> By raising an enhancement request in JIRA and attaching the patch to it.
>
>
I will see if I can find some time this week.
Thanks!
-- Josh
> On Sat, Jun 9, 2012 at 7:01 AM, Oleg Kalnichevski <[email protected]>
> 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: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
