Hmm, ok. I’d have to defer to David Smiley about whether that was an intended change.
I’m curious whether you can actually measure the difference in performance. If you can then that changes the urgency. Of course it’ll be a little more expensive for the replica serving shard2 on that machine to forward it to the replica serving shard1, but since it’s not going across the network IDK if it’s a consequential difference. Best, Erick > On Jul 20, 2020, at 10:04 AM, Jason J Baik <jason.j.b...@gmail.com> wrote: > > Our use case here is that we want to highlight a single document (against > user-provided keywords), and we know the document's unique key already. > So this is really not a distributed query, but more of a get by id, but we > use SolrClient.query() for highlighting capabilities. > And since we know the unique key, for speed gains, we've been making use of > the "_route_" param to limit the request to the shard containing the > document. > > Our use case aside, SOLR-11444 > <https://issues.apache.org/jira/browse/SOLR-11444> generally seems to be at > odds with the advertised use of the "_route_" param > https://lucene.apache.org/solr/guide/7_5/solrcloud-query-routing-and-read-tolerance.html#_route_-parameter > . > Solr is routing the request to the correct "node", but it no longer routes > to the correct "shard" on that node? > > > On Mon, Jul 20, 2020 at 9:33 AM Erick Erickson <erickerick...@gmail.com> > wrote: > >> First I want to check if this is an XY problem. Why do you want to do this? >> >> If you’re using CloudSolrClient, requests are automatically load balanced. >> And >> even if you send a top-level request (assuming you do NOT set >> distrib=false), >> then the request may be forwarded to another Solr node anyway. This is to >> handle the case where people are sending requests to a specific node, you >> don’t >> really want that node doing all the aggregating. >> >> Of course if you’re using an external load balancer, you can avoid all >> that. >> >> I’m not sure what the value is of sending a general request to a specific >> core in the same JVM. A “node” is really Solr running in a JVM, so there >> may be multiple of these on a particular machine, but the resolution >> takes that into account. >> >> If you have reason to ping a specific replica _only_ (I’ve often done this >> for >> troubleshooting), address the full replica and add “distrib=false”, i.e. >> http://…../solr/collection1_shard1_replica1?q=*:*&distrib=false >> >> Best, >> Erick >> >>> On Jul 20, 2020, at 9:02 AM, Jason J Baik <jason.j.b...@gmail.com> >> wrote: >>> >>> Hi, >>> >>> After upgrading from Solr 6.6.2 to 7.6.0, we're seeing an issue with >>> request routing in CloudSolrClient. It seems that we've lost the ability >> to >>> route a request to a specific core of a node. >>> >>> For example, if a host is serving shard 1 core 1, and shard 2 core >>> 1, @6.6.2, adding a "_route_=<value whose hash falls in shard 1 range>" >>> param was sufficient for CloudSolrClient to figure out the request should >>> go to shard 1 core 1, but @7.6.0, the request is routed to one of them >>> randomly. >>> >>> It seems the core-level url resolution has been removed from >>> CloudSolrClient at commit e001f352895c83652c3cf31e3c724d29a46bb721 around >>> L1053, as part of SOLR-11444 >>> <https://issues.apache.org/jira/browse/SOLR-11444>. The url the request >> is >>> sent to is now constructed only to the node level, and no longer to the >>> core level. >>> >>> There's a related issue for this at SOLR-10695 >>> <https://issues.apache.org/jira/browse/SOLR-10695>, and SOLR-9063 >>> <https://issues.apache.org/jira/browse/SOLR-9063> but not quite the >> same. >>> Can somebody please advise what the new way to achieve this nowadays is? >> >>
