You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Jason Baik (Jira)" <ji...@apache.org> on 2020/08/10 04:45:00 UTC

[jira] [Comment Edited] (SOLR-14630) CloudSolrClient doesn't pick correct core when server contains more shards

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

Jason Baik edited comment on SOLR-14630 at 8/10/20, 4:44 AM:
-------------------------------------------------------------

Attached is a test case demonstrating the problem: [^0001-SOLR-14630-Test-case-demonstrating-_route_-is-broken.patch]. 

We're finding the same problem as [~idjurasevic] as we're upgrading from Solr 6 to 7. The _route_ param no longer works as expected. The regression seems to have happened around L1061 in [https://github.com/apache/lucene-solr/commit/e001f352895c83652c3cf31e3c724d29a46bb721#diff-c8d54eacd46180b332c86c7ae448abaeR1065]. It made requests no longer be routed to a specific replica, but only to the node level. 

This:
{code:java}
ZkCoreNodeProps.getCoreUrl(nodeProps.getStr(ZkStateReader.BASE_URL_PROP), joinedInputCollections) {code}
Shouldn't have replaced:
{code:java}
url = coreNodeProps.getCoreUrl() {code}
Although they sound like they do the same thing, they actually don't. Only the latter produces a replica specific url. I guess the name of the method getCoreUrl() is little tricky. 

 


was (Author: jason.j.baik@gmail.com):
Attached is a test case demonstrating the problem: [^0001-SOLR-14630-Test-case-demonstrating-_route_-is-broken.patch].

 

We're finding the same problem as [~idjurasevic] as we're upgrading from Solr 6 to 7. The _route_ param no longer works as expected. The regression seems to have happened around L1061 in [https://github.com/apache/lucene-solr/commit/e001f352895c83652c3cf31e3c724d29a46bb721#diff-c8d54eacd46180b332c86c7ae448abaeR1065]. It made requests no longer be routed to a specific replica, but only to the node level. 

This:
{code:java}
ZkCoreNodeProps.getCoreUrl(nodeProps.getStr(ZkStateReader.BASE_URL_PROP), joinedInputCollections) {code}
Shouldn't have replaced:
{code:java}
url = coreNodeProps.getCoreUrl() {code}
Although they sound like they do the same thing, they actually don't. Only the latter produces a replica specific url. I guess the name of the method getCoreUrl() is little tricky. 

 

> CloudSolrClient doesn't pick correct core when server contains more shards
> --------------------------------------------------------------------------
>
>                 Key: SOLR-14630
>                 URL: https://issues.apache.org/jira/browse/SOLR-14630
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud, SolrJ
>    Affects Versions: 8.5.1, 8.5.2
>            Reporter: Ivan Djurasevic
>            Priority: Major
>         Attachments: 0001-SOLR-14630-Test-case-demonstrating-_route_-is-broken.patch
>
>
> Precondition: create collection with 4 shards on one server.
> During search and update, solr cloud client picks wrong core even _route_ exists in query param. In BaseSolrClient class, method sendRequest, 
>  
> {code:java}
> sortedReplicas.forEach( replica -> {
>   if (seenNodes.add(replica.getNodeName())) {
>     theUrlList.add(ZkCoreNodeProps.getCoreUrl(replica.getBaseUrl(), joinedInputCollections));
>   }
> });
> {code}
>  
> Previous part of code adds base url(localhost:8983/solr/collection_name) to theUrlList, it doesn't create core address(localhost:8983/solr/core_name). If we change previous code to:
> {quote}
> {code:java}
> sortedReplicas.forEach(replica -> {
>     if (seenNodes.add(replica.getNodeName())) {
>         theUrlList.add(replica.getCoreUrl());
>     }
> });{code}
> {quote}
> Solr cloud client picks core which is defined with  _route_ parameter.
>  
>   



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

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