Ryan McKinley wrote:
not sure if it is something we can do better or part of HttpClient...
From:
http://www.nabble.com/CLOSE_WAIT-td19959428.html
it seems to suggest you may want to call:
con.closeIdleConnections(0L);
But if you are creating a new MultiThreadedHttpConnectionManager for
each request, is seems odd you would have to explicitly close the
connection for each request.
What happens if you try using a SimpleHttpConnectionManager rather
then a MultiThreadedHttpConnectionManager? You can explicitly pass in:
I was thinking the same thing when i saw the other constructor.
I've modified the code to call the 'simple' version and will let it run
for an hour or three to make sure it works and doesn't exhibit the
behavior, so far it looks good and there are no CLOSE_WAITs (or
FIN_WAIT2's) showing up for longer than a couple of seconds. (according
to netstat -tn)
I'd petition we go back to the 'stupid' version by default that just
does what it is supposed to do, and leave the other one for 'experts'. I
can't even see how to tell the multi-threaded version to close itself
nicely ;(
to:
public CommonsHttpSolrServer(URL baseURL, HttpClient client,
ResponseParser parser, boolean useMultiPartPost) {
if that fixes things, it is a bit disturbing, but something we should
look into.
ryan
