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've marked oleg's answer as correct, as it highlights an important usage point about HttpClient's connection pooling.

To answer my specific original question, though, which was "Should I be trying to solve for 0 unused sockets or trying to maximize pooling?"

Now that the pooling solution is in place and working correctly the application throughput has increased by about 150%. I attribute this to not having to renegotiate SSL and multiple handshakes, instead reusing persistent connections in accordance with HTTP 1.1.

It is definitely worth working to utilize pooling as intended, rather than trying to hack around with calling ThreadSafeClientConnManager.shutdown() after each request etcetera. If, on the other hand, you were calling arbitrary hosts and not reusing routes the way I am you might easily find that it becomes necessary to do that sort of hackery, as the JVM might surprise you with the long life of CLOSE_WAIT designated sockets if you're not garbage collecting very often.

Answer 2

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.

Answer 3

One needs to pro-actively evict expired / idle connections from the connection pool, as in the blocking I/O model connections cannot react to I/O events unless they are being read from / written to. For details see

http://hc.apache.org/httpcomponents-client-dev/tutorial/html/connmgmt.html#d4e631