dsmiley commented on code in PR #2885:
URL: https://github.com/apache/solr/pull/2885#discussion_r1861223613
##########
solr/core/src/java/org/apache/solr/cli/ExportTool.java:
##########
@@ -660,8 +660,8 @@ class CoreHandler {
}
boolean exportDocsFromCore() throws IOException, SolrServerException {
-
- try (SolrClient client = CLIUtils.getSolrClient(baseurl, credentials))
{
+ // reference the replica's node URL, not the baseUrl in scope, which
could be anywhere
+ try (SolrClient client = CLIUtils.getSolrClient(replica.getBaseUrl(),
credentials)) {
Review Comment:
It's true that this change would break for such a scenario. Thankfully the
ExportTool is using the Solr/HTTP ClusterStateProvider instead of ZK; thus the
URLs may be rewritable by such a proxy thing since it'd be at the HTTP level.
But Solr the client would need to be configured to use XML instead of javabin,
but I think it's javabin by default. I could imagine adding special support
for this for CLUSTERSTATE or COLSTATUS
Despite that issue, I still believe in this change. I don't think it makes
sense for SolrCloud to go through such guessing efforts to resolve
collection/core ambiguity. Ideally we'd improve on that so that we wouldn't
have ambiguity. I could imagine a /solr/collectionName!shardName/select syntax
or similar.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
