[
https://issues.apache.org/jira/browse/SOLR-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Wartes updated SOLR-7493:
------------------------------
Attachment: SOLR-7493.patch
It looks like this happens because SolrDispatchFilter's getRemoteCoreURL
eventually takes the first viable entry from a HashMap.values list of cores.
HashMap.values ordering is always the same, if you load the HashMap with the
same data in the same order. So if the list from ZK is presented in the same
order on every node, every node will use the same ordering on every request.
There might be a better solution, but this patch would randomize that ordering
per-request.
My environment is a bit messed up at the moment, so I haven't done much more
than verify this compiles.
> Requests aren't distributed evenly if the collection isn't present locally
> --------------------------------------------------------------------------
>
> Key: SOLR-7493
> URL: https://issues.apache.org/jira/browse/SOLR-7493
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.0
> Reporter: Jeff Wartes
> Attachments: SOLR-7493.patch
>
>
> I had a SolrCloud cluster where every node is behind a simple round-robin
> load balancer.
> This cluster had two collections (A, B), and the slices of each were
> partitioned such that one collection (A) used two thirds of the nodes, and
> the other collection (B) used the remaining third of the nodes.
> I observed that every request for collection B that the load balancer sent to
> a node with (only) slices for collection A got proxied to one *specific* node
> hosting a slice for collection B. This node started running pretty hot, for
> obvious reasons.
> This meant that one specific node was handling the fan-out for slightly more
> than two-thirds of the requests against collection B.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
