[ 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