[
https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559349#action_12559349
]
patrick o'leary commented on SOLR-457:
--------------------------------------
In terms of reusing threads I used Executors.newCachedThreadPool which should
maintain a static pool of threads. Or so it says in the documentation. I'll try
profiling it when I get a chance.
The _connectionManger yep that's a good spot, need to overwrite
{code}
protected HttpClient getHttpConnection() {
return new HttpClient(getConnectionManager());
}
{code}
Makes sense to change the CommonsHttpSolrServer setConnectionTimeout,
setDefaultMaxConnectionsPerHost, setMaxTotalConnections to call
getConnectionManager() instead of using _connectionManager
unless having a setConnectionManager makes more sense.
At the moment I've just added a setConnectionManager in the
MultiThreadedHttpSolrServer, but that leaves me wondering do I need to abstract
the connection manger in the client implementation or is that over kill.
Because there will always be something new to set in your connection manager.
> A multi threaded implementation for solrJ
> -----------------------------------------
>
> Key: SOLR-457
> URL: https://issues.apache.org/jira/browse/SOLR-457
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
> Affects Versions: 1.3
> Reporter: patrick o'leary
> Priority: Minor
> Fix For: 1.3
>
> Attachments: multithreaded-solrj.patch
>
>
> Provide a multi threaded implementation of CommonsHttpSolrServer
> For usage with distributed searching in solr-303
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
