lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Gerlowski (JIRA)" <>
Subject [jira] [Commented] (SOLR-8830) client error messages should be consistent even when updates are internally routed to other nodes
Date Mon, 21 Mar 2016 11:56:25 GMT


Jason Gerlowski commented on SOLR-8830:

Short non-update here:

Spent a little time looking into this yesterday.  I didn't get far, but I did learn a few
things.  They might be of interest to others, but mainly I just want to jot them down here
so I have some notes to come back to when I pick this up again tonight.  (This stuff is all
probably common knowledge for those familiar with the update code).

When an update request is received in {{DistributedUpdateProcessor}} (thanks again btw Hoss)
by a non-leader, it is eventually forwarded via a call to {{SolrCmdDistributor.distribAdd()}}.
 Eventually, SolrCmdDistributor uses {{StreamingSolrClients}} to send requests to the other
Solr nodes.  StreamingSolrClients keeps track of any errors in a List of {{SolrCmdDistributor.Error}}
objects.  SolrCmdDistributor fetches these errors in its finish() method, which is invoked
by DistributedUpdateProcessor.

I saw some evidence that the leader isn't returning the right information (its response doesn't
contain the message about "bogus" and "foo_i"), and that the code-path detailed above would
handle things correctly if it had been given enough to work with.  I doubt my own work a bit
there, so I'm going to double check that when I pick this up in a bit.

Anyways, like I said, I haven't gotten far with this.  Just wanted to jot down a few notes
for later, and maybe someone could correct any mistakes/misconceptions I had.

> client error messages should be consistent even when updates are internally routed to
other nodes
> -------------------------------------------------------------------------------------------------
>                 Key: SOLR-8830
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Hoss Man
> As things stand today, clients sending documents to a SolrCloud cluster may or may not
get a useful error message depending on whether the update goes directly to the appropriate
leader, or if it gets routed internally.
> A trivial example of this is shown below, and can be reproduced using "bin/solr -e cloud"
using 2 nodes, 1 shard, 2 replicas...
> {noformat}
> $ curl -H 'Content-Type: application/json' --data-binary '[{"id":"a", "foo_i":"bogus"}]'
> {
>   "responseHeader":{
>     "status":400,
>     "QTime":49},
>   "error":{
>     "metadata":[
>       "error-class","org.apache.solr.common.SolrException",
>       "root-error-class","java.lang.NumberFormatException",
>       "error-class","org.apache.solr.common.SolrException",
>       "root-error-class","org.apache.solr.common.SolrException"],
>     "msg":"Bad Request\n\n\n\nrequest:",
>     "code":400}}
> $ curl -H 'Content-Type: application/json' --data-binary '[{"id":"a", "foo_i":"bogus"}]'
> {
>   "responseHeader":{
>     "status":400,
>     "QTime":9},
>   "error":{
>     "metadata":[
>       "error-class","org.apache.solr.common.SolrException",
>       "root-error-class","java.lang.NumberFormatException"],
>     "msg":"ERROR: [doc=a] Error adding field 'foo_i'='bogus' msg=For input string: \"bogus\"",
>     "code":400}}
> {noformat}
> ...note that while the "root-error-class" of NumberFormatException is preserved in both
cases, the actual message indicating the specific problem (field {{foo_i}} contains an invalid
value {{bogus}})  is lost in the case where the update was internally forwarded.
> Even if we never make the err msgs perfectly identical between those requests (because
it might be useful to indicate what node/shard reported the error in case it's node specific)
we should at least ensure some minimum consistency in the information returned -- ie: always
include the remote exception message as a suffix. of the Exception.getMessage().
> We should likewise ensure that SolrExceptions thrown by SolrJ clients (HttpSolrClient,
or CloudSolrClient, etc...) due to remote errors adequately propogate the msg text -- especially
when it's a 4xx error.

This message was sent by Atlassian JIRA

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

View raw message