[
https://issues.apache.org/jira/browse/SOLR-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204077#comment-15204077
]
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: https://issues.apache.org/jira/browse/SOLR-8830
> 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"}]'
> 'http://localhost:7574/solr/gettingstarted/update?indent=true'
> {
> "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:
> http://127.0.1.1:8983/solr/gettingstarted_shard1_replica2/update?update.chain=add-unknown-fields-to-the-schema&update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.1.1%3A7574%2Fsolr%2Fgettingstarted_shard1_replica1%2F&wt=javabin&version=2";,
> "code":400}}
> $ curl -H 'Content-Type: application/json' --data-binary '[{"id":"a",
> "foo_i":"bogus"}]'
> 'http://localhost:8983/solr/gettingstarted/update?indent=true'
> {
> "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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
