[ https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559340#action_12559340 ]
timmsc edited comment on SOLR-457 at 1/21/08 7:26 AM: --------------------------------------------------------- Currently with Solrj, if you want to take advantage of the connection pooling, I think you need to create a single instance of CommonsHttpSolrServer in your application (and if you aren't, you are better off using SimpleHttpConnectionManager). So, it seems to make sense to make it easier to use in this fashion. This could be made more general purpose though if process just took a single request and returned a single response and you called it once for each server. This would abstract out the threading and connection pooling while not constraining the class to something designed primarily for SOLR-303. A couple of other comments: The threads should probably be pooled rather than creating and destroying on each request. While creating and destroying threads has gotten faster, pooling is usually beneficial. Unless I'm mistaken, it appears that your connectionManager is different from the _connectionManager in CommonsHttpSolrServer, so the methods that you didn't override will not work correctly, e.g., setConnectionTimeout(). Neither the CommonsHttpSolrServer currently in Solrj nor this patch appear to allow setting of the read timeout: setSoTimeout(int timeout) or the connection manager timeout: setConnectionManagerTimeout(long timeout). Other HttpClient options such as disabling Nagle's algorithm are probably not as important. This should probably be opened as a separate JIRA issue (edit: see SOLR-462). was (Author: timmsc): Currently with Solrj, if you want to take advantage of the connection pooling, I think you need to create a single instance of CommonsHttpSolrServer in your application (and if you aren't, you are better off using SimpleHttpConnectionManager). So, it seems to make sense to make it easier to use in this fashion. This could be made more general purpose though if process just took a single request and returned a single response and you called it once for each server. This would abstract out the threading and connection pooling while not constraining the class to something designed primarily for SOLR-303. A couple of other comments: The threads should probably be pooled rather than creating and destroying on each request. While creating and destroying threads has gotten faster, pooling is usually beneficial. Unless I'm mistaken, it appears that your connectionManager is different from the _connectionManager in CommonsHttpSolrServer, so the methods that you didn't override will not work correctly, e.g., setConnectionTimeout(). Neither the CommonsHttpSolrServer currently in Solrj nor this patch appear to allow setting of the read timeout: setSoTimeout(int timeout) or the connection manager timeout: setConnectionManagerTimeout(long timeout). Other HttpClient options such as disabling Nagle's algorithm are probably not as important. This should probably be opened as a separate JIRA issue. > 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.