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]
