[
https://issues.apache.org/jira/browse/SOLR-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17951398#comment-17951398
]
Jason Gerlowski commented on SOLR-17568:
----------------------------------------
It's easy enough to say "well don't do it", but a lot of our users don't have
that choice. Maybe they consume Solr through a service offering that only
provides a single LB endpoint, or Solr is provided to them internally by some
other team that doesn't expose individual nodes for security reasons, or...
That's a big set of users, and IMO we shouldn't break things for them without
giving them an alternative.
The v2 API *could* solve this problem - the path structure it offers avoids the
ambiguity issue that you're concerned about. But the plumbing isn't there
currently - v2 doesn't make any attempt to lookup remote cores and forward.
Only v1 did this.
e.g. Given a core "gettingstarted_shard2_replica_n1" that lives on
localhost:7574:
{code}
$ curl -ilk -X GET
"http://localhost:8983/cores/gettingstarted_shard2_replica_n1/select?q=*:*";
HTTP/1.1 404 Not Found
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 402
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 404 Not Found</title>
</head>
<body><h2>HTTP ERROR 404 Not Found</h2>
<table>
<tr><th>URI:</th><td>/cores/gettingstarted_shard2_replica_n1/select</td></tr>
<tr><th>STATUS:</th><td>404</td></tr>
<tr><th>MESSAGE:</th><td>Not Found</td></tr>
<tr><th>SERVLET:</th><td>-</td></tr>
</table>
</body>
</html>
{code}
I know you raised this on the mailing list months back, and I even put forward
v2 as a potential path forward back then. But I thought the timeline would be
different and that we'd offer an alternative (be it matrix path-params, v2 API
support, etc.) before we nuked what already existed.
> Remove remote *core* query in SolrCloud mode
> --------------------------------------------
>
> Key: SOLR-17568
> URL: https://issues.apache.org/jira/browse/SOLR-17568
> Project: Solr
> Issue Type: Task
> Components: SolrCloud
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Labels: pull-request-available
> Fix For: main (10.0)
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> If a SolrCloud node receives a request with a local core name (not a
> collection name), it will be handled by the local core. But it even works
> with a remote core -- it'll be forwarded to the node that has a core by that
> name. I think there's no use-case for that -- users should only reference
> collections (any node) or a core on a node where it's known to exist (on that
> node!) since it's a core not a cluster concept. This got my attention
> because the functionality requires iterating all collections. This would
> happen for any request when a collection/core is not known to the node (and
> may not exist at all). I shall remove this in Solr 10.
> There is exactly one test for this functionality --
> {{org.apache.solr.cloud.AbstractBasicDistributedZk2TestBase#addAndQueryDocs}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
