I have a web-based application and a client, both written in Java. For what it\'s worth, the client and server are both on Windows. The client issues HTTP GETs via Apache HttpC
If you are using long running GETs, you should timeout on the client side at twice the server timeout, as you have discovered.
On a TCP where the client send a message and expects a response, if the server were to crash, and restart (lets say for the point of examples) then the client would still be waiting on the socket to get a response from the Server yet the server is no longer listening on that socket.
The client will only discover the socket is closed on the server end once it sends more data on that socket, and the server rejects this new data, and closes the socket.
This is why you should have client side time-outs on requests.
But as your server is not crashing, if the server was multi threaded, and thread socket for that client closed, but at that time ( duration minutes) the client has an connectivity outage, then the end socket hand-shaking my be lost, and as you are not sending more data to the server from the client, your client is once again left hanging. This would tie in to your flaking connection observation.