[
https://issues.apache.org/jira/browse/SOLR-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-9063:
---
Attachment: SOLR_9063.patch
Testing revealed at least one issue: It's insufficient for the condition to be
simply {{collectionNames.size() > 1}} because the collection String might
actually be a comma delimited list. So that brings me to: {{if
(collectionNames.size() > 1 && reqParams.get(UpdateParams.COLLECTION) ==
null)}}. ...
Then StressHdfsTest failed reproducibly with seed A8BBAE62E21BB966. There was
some other failure but it didn't reproduce/happen again. The failure is Jetty
returning an HTML page of 404 status trying to reach a specific core URL.
Here's the trace:
{noformat}
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:574)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:366)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1204)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:965)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:901)
at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at
org.apache.solr.cloud.hdfs.StressHdfsTest.createAndDeleteCollection(StressHdfsTest.java:208)
at
org.apache.solr.cloud.hdfs.StressHdfsTest.test(StressHdfsTest.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
{noformat}
I have suspicions it's an issue with the test but I'm not sure. I don't have
time to debug this one further, and as this isn't pressing I think I'll move on
from this issue for now.
Stepping back a bit, might it make more sense to always go to the collection
level URL at an appropriate node? Kinda the opposite of what I've been trying
to do. That would be consistent, which is nice. But then ideally, to retain
some of the direct routing going on here, HttpSolrCall would have to gain the
ability to dispatch based on {{\_route\_}}. That sounds like a better path,
actually, although the thought of it sheds more light on duplicated routing
logic for different contexts: CloudSolrClient, HttpSolrCall, HttpShardHandler.
Maybe elsewhere too. :-/
> CloudSolrClient with _route_ shouldn't require collection param to disambig
> cores
> -
>
> Key: SOLR-9063
> URL: https://issues.apache.org/jira/browse/SOLR-9063
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud, SolrJ
>Affects Versions: 4.10.4
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_9063.patch
>
>
> CloudSolrClient uses {{\_route\_}} to know where to send a request It sorta
> works -- it'll go to an appropriate _node_. But it will only go to the
> correct core on that node if the {{collection}} parameter is explicitly
> added. In another words, it ignores the default collection configured on
> CloudSolrClient. It also seems to ignore "collection" parameter to the
> protected method sendRequest for this purpose too. As I write this, see line
> 1139 on master.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
