[
https://issues.apache.org/jira/browse/SOLR-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661971#action_12661971
]
Andrzej Rusin commented on SOLR-861:
------------------------------------
Alternatively, the problem can be solved in client code by reusing the
HttpClient across the CommonsHttpSolrServers like this:
if (httpClient == null) {
server = new CommonsHttpSolrServer(url);
httpClient = server.getHttpClient();
} else {
server = new CommonsHttpSolrServer(url, httpClient);
}
It has the advantage of pooling the HTTP connections inside the HttpClient's
MultiThreadedHttpConnectionManager.
I am using this approach in production with good results.
> SOLRJ Client does not release connections 'nicely' by default
> -------------------------------------------------------------
>
> Key: SOLR-861
> URL: https://issues.apache.org/jira/browse/SOLR-861
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 1.3
> Environment: linux
> Reporter: Ian Holsman
> Attachments: SimpleClient.patch
>
>
> as-is the SolrJ Commons HttpServer uses the multi-threaded http connection
> manager. This manager seems to keep the connection alive for the client and
> does not close it when the object is dereferenced.
> When you keep on opening new CommonsHttpSolrServer instances it results in a
> socket that is stuck in the CLOSE_WAIT state. Eventually this will use up all
> your available file handles, causing your client to die a painful death.
> The solution I propose is that it uses a 'Simple' HttpConnectionManager which
> is set to not reuse connections if you don't specify a HttpClient.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
