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
