You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Per Steffensen (Created) (JIRA)" <ji...@apache.org> on 2012/04/20 12:12:42 UTC
[jira] [Created] (SOLR-3384) Custom SolrServer chains - mixing
SolrServer-subclass properties as you like to
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
Fix For: 4.0
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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (SOLR-3384) Custom SolrServer chains - mixing
SolrServer-subclass properties as you like to
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org