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? > >
