JVM-based longpoll/comet client: routers killing idle connections

I currently have a JVM-based network client that does an HTTP long poll (aka comet) request using the standard java.net.HttpURLConnection. I have timeout set very high for the connection (1 hour). For most users it works fine. But some users do not receive the data sent from the server and eventually time out after 1 hour.

M开发者_运维知识库y theory is that a (NAT) router is timing out and discarding their connections because they are idle too long before the server sends any data.

My questions then are:

Can I enable TCP keep-alive for the connections used by java.net.HttpURLConnection? I could not find a way to do this.

Is there a different API (than HttpURLConnection) I should be using instead?

Other solutions?

java.net.HttpURLConnection handles Keep-Alive header transparently, it can be controlled and it is on by default. But your problem is not in Keep-Alive, which is a higher level flag indicating that the server should close the connection after handling the first request but rather waiting for the next one.

In your case probably something on the lower level of OSI stack interrupts the connection. Because keeping an open but idle TCP connection for such a long period of time is never a good choice (FTP protocol with two open connections: one for commands and one for data has the same problem), I would rather implement some sort of disconnect/retry fail-safe procedure on the client side.

In fact safe limit would probably be just few minutes, not hours. Simply disconnect from the HTTP server pro-actively every 60 seconds or 5 minutes. Should do the trick.

There does not appear to be a way to turn on TCP keep-alive for HttpURLConnection.

Apache HttpComponents will be an option when version 4.2 comes out with TCP keep-alive support.