[
https://issues.apache.org/jira/browse/SOLR-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3384:
---------------------------
Fix Version/s: (was: 4.0)
removing fixVersion=4.0 since there is no evidence that anyone is currently
working on this issue. (this can certainly be revisited if volunteers step
forward)
> Custom SolrServer chains - mixing SolrServer-subclass properties as you like
> to
> -------------------------------------------------------------------------------
>
> Key: SOLR-3384
> URL: https://issues.apache.org/jira/browse/SOLR-3384
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 3.5
> Reporter: Per Steffensen
> Priority: Minor
> Labels: design, separation, solrj, solrserver
>
> Today it is like this
> - LBHttpSolrServer is load-balancing over HttpSolrServers
> - ConcurrentUpdateSolrServer is using HttpSolrServer internally for sending
> requests (or its not, but I believe (without having looked thoroughly into
> it) it ought to)
> - CloudSolrServer is using LBHttpSolrServer to load-balance over
> HttpSolrServer (one for each slice in a collection)
> IMHO it is a little to hardcoded to release its full potential. Those
> SolrServers (or some of them) ought to take the "internally used
> SolrServer(s)" or a factory to help creating those as a parameter
> (constructor and/or set-method). E.g.
> - LBHttpSolrServer should just be called LBSolrServer and not be hardcoded to
> use HttpSolrServers internally. Instead of taking a list of URLs to
> load-balance over (using HttpSolrSever) it should just take a list of
> SolrServers to load-balance over.
> - ConcurrentUpdateSolrServer should not be hardcoded to use HttpSolrServer
> internally. Instead take SolrServers (or a factory to construct those) to use
> internally as input from the outside.
> - CloudSolrServer of course will need to load-balance over the slices in the
> collection (that is its core property), but not necessarily directly using
> HttpSolrServers. Instead it should probably take a factory accepting a URL in
> its "createInstance"-method to be used when creating the SolrServers to
> load-balance over.
> Making SolrServer more generic like this, having them deal only with their
> core reason for existing (separation of concerns), you will be able to create
> you own custom chains of SolrServers - e.g. a "LBSolrSever -> CloudSolrSevers
> -> LBSolrServer -> ConcurrentSolrServers -> HttpSolrServer" chain which I
> believe I would like to use to load-balance asynchronously over several
> collections.
> This improvement is very hard to do before SOLR-3382 and SOLR-3383 has been
> solved, because you will not be able to add Concurrent(Update)SolrServer to
> your chain without limiting the functionality of your chain (update only) and
> you will not be able to get responses back.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
