[
https://issues.apache.org/jira/browse/SOLR-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245665#comment-14245665
]
Shawn Heisey commented on SOLR-6832:
------------------------------------
CloudSolrServer does load balance, so you do not need an external load
balancer. Internally, it uses changes in the zookeeper clusterstate to add and
remove URLs on an instance of LBHttpSolrServer, which in turn uses
HttpSolrServer for each of those URLs.
https://lucene.apache.org/solr/4_10_2/solr-solrj/org/apache/solr/client/solrj/impl/LBHttpSolrServer.html
The name preferLocalShards is perfect ... and I think a good case can be made
for CloudSolrServer using this for queries (probably via a query URL parameter)
by default.
> Queries be served locally rather than being forwarded to another replica
> ------------------------------------------------------------------------
>
> Key: SOLR-6832
> URL: https://issues.apache.org/jira/browse/SOLR-6832
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.10.2
> Reporter: Sachin Goyal
>
> Currently, I see that code flow for a query in SolrCloud is as follows:
> For distributed query:
> SolrCore -> SearchHandler.handleRequestBody() -> HttpShardHandler.submit()
> For non-distributed query:
> SolrCore -> SearchHandler.handleRequestBody() -> QueryComponent.process()
> \\
> \\
> \\
> For a distributed query, the request is always sent to all the shards even if
> the originating SolrCore (handling the original distributed query) is a
> replica of one of the shards.
> If the original Solr-Core can check itself before sending http requests for
> any shard, we can probably save some network hopping and gain some
> performance.
> \\
> \\
> We can change SearchHandler.handleRequestBody() or HttpShardHandler.submit()
> to fix this behavior (most likely the former and not the latter).
--
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
