[ 
https://issues.apache.org/jira/browse/SOLR-14935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17218010#comment-17218010
 ] 

Varun Thacker commented on SOLR-14935:
--------------------------------------

I am not using preferLocalShards=true . If you see 
[https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L284]
 , we're just looking at the first collection in the alias list. So depending 
on the number of collection in your alias the odds will change.

> Solr can forward request ( remoteQuery ) even if there are local cores present
> ------------------------------------------------------------------------------
>
>                 Key: SOLR-14935
>                 URL: https://issues.apache.org/jira/browse/SOLR-14935
>             Project: Solr
>          Issue Type: Task
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Varun Thacker
>            Priority: Major
>
> Noticed an odd interaction where search queries are being proxied ( treated 
> as remoteQuery ) even when there are cores from that alias on the querying 
> node
>  * Running Solr 7.7.3 and querying via CloudSolrClient
>  * We use aliases and query with the alias name in CloudSolrClient
>  * CloudSolrClient creates a list of all replicas from the alias ( after 
> resolving it ) and then shuffles the list picking one Solr node to query 
> against
>  * When Solr receives the request, it only looks at the first collection from 
> the alias and tries to find a local core
>  * Anytime that isn't the case, it makes a remoteQuery ,  proxying the 
> request to machineX which has a local core of the first collection from the 
> alias.
>  
> I think we can make Solr check against all collections in the alias to see if 
> there is a local node present without performance implications.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to