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. > 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. Oleg > 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]
