[ 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.