I had similar issues and I solved it by writing my own retry-handler.
I'm not sure if your issues are the same I experienced, but if they are you
could try this:
The default retry-handler of does not handle socket-timeout exceptions well
if you are have a shared connection pool. It seems like that if a stale
connection is picked up for another http-request, it may time-out and give
a failure without retrying.
/**
* Retries on failing Http connections. The default handler didn't deal
with SocketExceptions at
* all... and those are the ones we get most.
*
* @author Anton Spaans
*/
private static class RetryHandler implements HttpRequestRetryHandler {
@Override
public boolean retryRequest(IOException exception, int executionCount,
HttpContext context) {
if (exception == null) {
throw new IllegalArgumentException("Exception parameter may not
be null");
}
if (context == null) {
throw new IllegalArgumentException("HTTP context may not be
null");
}
if (executionCount > 3) {
return false;
}
if (exception instanceof NoHttpResponseException) {
// Retry if the server dropped connection on us
return true;
}
if (exception instanceof SocketException) {
// Retry if the server closed socket on us
return true;
}
if (exception instanceof InterruptedIOException) {
// Timeout
return false;
}
if (exception instanceof UnknownHostException) {
// Unknown host
return false;
}
if (exception instanceof SSLHandshakeException) {
// SSL handshake exception
return false;
}
Boolean b =
(Boolean)context.getAttribute(ExecutionContext.HTTP_REQ_SENT);
boolean sent = (b != null && b.booleanValue());
if (!sent) {
// Retry if the request has not been sent fully or
// if it's OK to retry methods that have been sent
return true;
}
HttpRequest request = (HttpRequest)
context.getAttribute(ExecutionContext.HTTP_REQUEST);
boolean idempotent = !(request instanceof HttpEntityEnclosingRequest);
if (idempotent) {
// Retry if the request is considered idempotent
return true;
}
// otherwise do not retry
return false;
}
}
Then, if you have your DefaultHttpClient, you can call this:
defaultHttpClient.setHttpRequestRetryHandler(new RetryHandler());
(note that you can't get hold of the 'DefaultHttpClient' that is wrapped by
the AndroidHttpClient: I needed to copy the code of AndroidHttpClient into
our own code base and modify it such that I could call the
setHttpRequestHandler(...))
On Tuesday, November 6, 2012 5:22:16 AM UTC-5, Thomas Bouron wrote:
>
> Hello.
>
> I'm facing an issue that I cannot get a rid of it. Let me explain:
> I use for my app the AndroidHttpClient to make connection to a REST
> server. Everything works as expected except for a few of my users. At some
> point, my code throws an SocketTimeoutException. So I search all over the
> web and I found that it seems to be related to the DNS lookup. The solution
> to counter part is to use HttpURLConnection.
>
> Now the funny part: On the emulator at home, everything is fine,
> impossible to reproduce the issue. But on the emulator at work (behind a
> transparent proxy) I got a really weird behavior. Sometimes it works,
> sometimes not. Event if I change the AndroidHttpClient
> to HttpURLConnection, I got the same result. Increasing the timeout doesn't
> solve the problem either, it just increase the time before reaching
> the SocketTimeoutException. Regarding to my research, i also tried to
> change the URL by the IP of the REST server but nothing changed.
>
> So now I got any idea left, that's why I'm posting here. Is anyone already
> caught that?
>
> Thanks in advance.
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
