Riad,
Per default HttpClient does not automatically retry requests upon
connection timeout. However, nothing prevents you from providing a
custom retry handler to override this behavior:
public class DefaultHttpMethodRetryHandler
implements HttpMethodRetryHandler {
...
public boolean retryMethod(
final HttpMethod method,
final IOException exception,
int executionCount) {
...
if (executionCount > this.retryCount) {
// Do not retry if over max retry count
return false;
}
if (exception instanceof NoHttpResponseException) {
// Retry if the server dropped connection on us
return true;
}
if (exception instanceof InterruptedIOException) {
// Timeout
return false; // return true instead
}
...
// otherwise do not retry
return false;
}
See <http://jakarta.apache.org/commons/httpclient/3.0/exception-
handling.html#Custom%20exception%20handler> for details
Cheers,
Oleg
On Mon, 2005-02-14 at 16:21 +0300, Riad Souissi wrote:
> Hi,
>
> I noticed that the Retry handler mechanism does not work when the client
> cannot initiate a connection (which throws
> java.net.ConnectionException).
> This happens for me for instance when there is proxy and a tunneling in
> the picture and sometimes there are connectivity problems.
> Of course, it is possible to build the retry on top of the HTTPClient,
> but it would be nice to use the same RetryHandler framework for that.
>
> I believe a ConnectionException is a typical transiant error that can be
> retried safely for those who want to enable it.
> Any opinion ?
>
> thanks
> riad
>
>
> DiscalimerThe information in this email and in any files transmitted with it,
> is intended only for the addressee and may contain confidential and/or
> privileged material.
> Access to this email by anyone else is unauthorized. If you receive this in
> error,
> please contact the sender immediately and delete the material from any
> computer.
> If you are not the intended recipient, any disclosure, copying, distribution
> or
> any action taken or omitted to be taken in reliance on it, is strictly
> prohibited.
> Statement and opinions expressed in this e-mail are those of the sender, and
> do not
> necessarily reflect those of STC.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
