[jira] [Commented] (SOLR-8830) client error messages should be consistent even when updates are internally routed to other nodes

["Kevin Risden (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15190061#comment-15190061 ] 

Kevin Risden commented on SOLR-8830:
------------------------------------

{quote}
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.
{quote}

This is definitely currently not the case with HttpSolrClient and streams. 401 errors are swallowed and most other errors are probably wrong as well. I sent a message to the dev list about this yesterday [here|http://mail-archives.apache.org/mod_mbox/lucene-dev/201603.mbox/%3CCAAtMDmPVmWX4EHjN0B=S30wyCk0MX7zX5k492cU7GNNbTi1PBA@mail.gmail.com%3E] after discovering in SOLR-8213. 

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org