[
https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561868#action_12561868
]
Yonik Seeley commented on SOLR-457:
-----------------------------------
OK, I'm just getting back to distributed search stuff...
My first inclination on how to handle this (the SolrJ part) was to
- add a constructor to CommonsHttpSolrServer that takes an HttpClient
- add a getHttpClient()
- perhaps remove methods that deal with setting connection timeouts, etc...
don't duplicate the interface of HttpClient
- add a constructor with common settings (timeout, retry, etc) for when the
user doesn't supply the HttpClient
Then, in distributed search land, we could either create SolrServers on the fly
(having them all share a single HttpClient), or if SolrServers are expensive to
create, we could cache them per shard.
Looking at this particular patch, I'm not sure it's the right direction. It
maintains a list of solr servers and sends the same request to each. There are
a number of places in SOLR-303 where we need to send different requests to
different shards (so we would be unable to re-use a single
MultiThreadedHttpSolrServer.
I think we also need to be clear in SolrJ (i.e. in the javadoc) what is
thread-safe and what is not.
> 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
> 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.
