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:
new HttpClient( new SimpleHttpConnectionManager() )
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
Hi Ryan.
the problem is with the HttpClient class.
the SimpleHttpConnectionManager by default hangs onto a connection "just
in case".
It needs to be called like:
CommonsHttpSolrServer solrServer;
SimpleHttpConnectionManager cm = new
SimpleHttpConnectionManager(true);
HttpClient httpClient = new HttpClient(cm);
solrServer = new CommonsHttpSolrServer(solrURL, httpClient);
solrServer.optimize();
cm.shutdown();
I'm not sure the 'shutdown' method is required, but the code now has
*NO* CLOSE_WAITS after running for 3-4 hours.
I'll stick up a jira with makes 'SimpleHttpConnectionManager(true)' the
default.
regards
Ian
