Home/ Questions/Q 8146455
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T14:00:24+00:00

I’m using DefaultHttpClient with a ThreadSafeClientConnManager on Android (2.3.x) to send HTTP requests to

  • 0

I’m using DefaultHttpClient with a ThreadSafeClientConnManager on Android (2.3.x) to send HTTP requests to a my REST server (embedded Jetty).

After ~200 seconds of idle time, the server closes the TCP connection with a [FIN]. The Android client responds with an [ACK]. This should and does leave the socket in a half-closed state (server is still listening, but can’t send data).

I would expect that when the client tries to use that connection again (via HttpClient.execute), DefaultHttpClient would detect the half-closed state, close the socket on the client side (thus sending it’s [FIN/ACK] to finalize the close), and open a new connection for the request. But, there’s the rub.

Instead, it sends the new HTTP request over the half-closed socket. Only after sending is the half-closed state detected and the socket closed on the client-side (with the [FIN] sent to the server). Of course, the server can’t respond to the request (it had already sent its [FIN]), so the client thinks the request failed and automatically retries via a new socket/connection.

The end result is that server sees and processes two copies of the request.

Any ideas on how to fix this? (My server does the correct thing with the second copy, but I’m annoyed that the payload is transmitted twice.)

Shouldn’t DefaultHttpClient detect that the socket was closed when it first tries to write the new HTTP packet, close that socket immediately, and start a new one? I’m baffled as to how a new HTTP request is sent on a socket minutes after the server sent a [FIN].

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is a general limitation of the blocking I/O in Java. There is simply no way of finding out whether or not the opposite endpoint has closed connection other than by attempting to read from the socket. Apache HttpClient works this problem around by employing the so stale connection check which is essentially a very brief read operation. However, the check can and often is disabled. In fact it is often advisable to have it disabled due to extra latency the check introduces. I have no idea how exactly the version of HttpClient shipped with Android behaves in this regard but you could try explicitly enabling the check by using an appropriate config parameter.

    A better solution to this problem might be evicting connections from the connection pool that have been idle over a particular period of time (say 150 seconds) after a period of inactivity.

    http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d5e652

    • 0