[
https://issues.apache.org/jira/browse/SOLR-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208761#comment-16208761
]
David Smiley commented on SOLR-11292:
-------------------------------------
I noticed that logic too [~varunthacker] while working on SOLR-11444.
[~ichattopadhyaya] I recall you added the stateProvider stuff. Would there be
a performance problem if CloudSolrClient resolved aliases first, thereby doing
an HTTP fetch for aliases that would otherwise have never occurred if you're
not even using the aliases? Probably not a big deal but the thought crossed my
mind.
> Querying against an alias can lead to incorrect routing
> -------------------------------------------------------
>
> Key: SOLR-11292
> URL: https://issues.apache.org/jira/browse/SOLR-11292
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Varun Thacker
> Assignee: Varun Thacker
>
> collection1 has 2 shards and 1 replica
> collection2 has 8 shards and 1 replica
> I have 8 nodes so collection2 is spread across all 8 , while collection1 is
> hosted by two nodes
> If we create an alias called "collection1" and point it to "collection2".
> Querying against the alias "collection1" works as expected but what I noticed
> was the top level queries would only hit 2 out of the 8 JVMs when querying
> using SolrJ
> It turns out that SolrJ is using the state.json of collection1 ( the actual
> collection ) and routing queries to only those nodes.
> There are two negatives to this:
> - If those two nodes are down all queries fail.
> - Top level queries are only routed to those two nodes thus causing a skew
> in the top level requests
> The obvious solution would be to use the state.json file of the underlying
> collection that the alias is pointing to . But if we have the alias pointing
> to multiple collections then this might get tricky?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
