You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Greg Pendlebury (JIRA)" <ji...@apache.org> on 2016/11/06 21:44:58 UTC
[jira] [Commented] (SOLR-4823) Split LBHttpSolrServer into two
classes one for the solrj use case and one for the solr cloud use case
[ https://issues.apache.org/jira/browse/SOLR-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15642463#comment-15642463 ]
Greg Pendlebury commented on SOLR-4823:
---------------------------------------
I know that my question will be off-topic for this particular issue, but it seems that it might be a viable launching point for a customization our team has been considering in-house. We were thinking of trying out the addition of one or more nodes in the cluster that had no allocated range hash in clusterstate (whether or not we needed to modify to code to achieve this we haven't looked yet).
Their purpose would be to act as search entry points for the cluster with more stable JVM performance (because they manage no lucene segments) as well as internalizing cluster security at the OS level. Right now, in a 200 replica cluster we need to let any/all SolrJ clients have access to the ZK ensemble as well as ports on every replica. It also makes managing threading (such as in the default http client thread pool) annoying to configure and test for performance.
With [~phloy]'s patch we could still make use of SolrJ, but just provide a small whitelist of our 'search nodes' and keep client-side requirements for searching very simple in terms of security and thread management.
> Split LBHttpSolrServer into two classes one for the solrj use case and one for the solr cloud use case
> ------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4823
> URL: https://issues.apache.org/jira/browse/SOLR-4823
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: philip hoy
> Priority: Minor
> Attachments: SOLR-4823.patch, SOLR-4823.patch
>
>
> The LBHttpSolrServer has too many responsibilities. It could perhaps be broken into two classes, one in solrj to be used in the place of an external load balancer that balances across a known set of solr servers defined at construction time and one in solr core to be used by the solr cloud components that balances across servers dependant on the request.
> To save code duplication, if much arises an abstract bass class could be introduced in to solrj.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org