How can I ensure that my HttpClient 4.1 does not leak sockets?

Question

My server uses data from an internal web service to construct its response, on a per request basis. I\'m using Apache HttpClient 4.1 to make the requests. Each initial request

Answer 1

I had the same issue and solved it using the suggesting found here: here. The author touches on some TCP basics:

When a TCP connection is about to close, its finalization is negotiated by both parties. Think of it as breaking a contract in a civilized manner. Both parties sign the paper and it’s all good. In geek talk, this is done via the FIN/ACK messages. Party A sends a FIN message to indicate it wants to close the socket. Party B sends an ACK saying it received the message and is considering the demand. Party B then cleans up and sends a FIN to Party A. Party A responds with the ACK and everyone walks away.

The problem comes in when B doesn’t send its FIN. A is kinda stuck waiting for it. It has initiated its finalization sequence and is waiting for the other party to do the same.

He then mentions RFC 2616, 14.10 to suggest setting up an http header to solve this issue:

postMethod.addHeader("Connection", "close");

Honestly, I don't really know the implications of setting this header. But it did stop CLOSE_WAIT from happening on my unit tests.