[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
