The current design of libclient_java connection management is inflexible, inefficient, and difficult to maintain.

Inflexible in that there is only one way of doing connection management, when in reality, different applications call for different strategies, for example in multithreading, timeout setting, etc.
Inefficient in that the current implementation opens and closes http connections and ssl sockets on each call. That places a higher load on the server, which has to spend more time performing handshakes than is necessary.
It's difficult to maintain, as each api method (55+) is responsible for handling connection close.

All advice is about use of HttpClient is for the application to share 1 instance of HttpClient and it's underlying HttpConnectionManager. This solves all three of the above problems, so the key is to implement without major change to the existing interface.

Accordingly, the proposed design changes are:

to share the httpClient within the D1Node method calls.¶

to implement the bridge pattern (to separate connection-management from service api logic) through addition of a new constructor: D1Node(String baseUrl, HttpClient client)¶

maintain backward compatibility by keeping the old constructor and providing a DefaultHttpClient¶

share the httpClient across D1Node instances by exposing the underlying httpClient (D1Node.getHttpClient()) and holding this shared httpClient in D1Client. All D1Nodes instantiated via D1Client will share the same httpClient instance (and it's connection manager)¶

upgrade to use apache HttpClient 4.2 (GA), released May 2012.¶

revisit the CLOSE_WAIT situation, and test to see if the CLOSE_WAIT problem reappears.¶