lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Updated] (SOLR-9063) CloudSolrClient with _route_ shouldn't require collection param to disambig cores
Date Thu, 05 May 2016 20:49:12 GMT


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:

at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(
	at org.apache.solr.client.solrj.impl.HttpSolrClient.request(
	at org.apache.solr.client.solrj.impl.HttpSolrClient.request(
	at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(
	at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(
	at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(
	at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(
	at org.apache.solr.client.solrj.impl.CloudSolrClient.request(
	at org.apache.solr.client.solrj.SolrRequest.process(
	at org.apache.solr.client.solrj.SolrClient.commit(
	at org.apache.solr.client.solrj.SolrClient.commit(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(
	at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(
	at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(
	at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(
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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message