[
https://issues.apache.org/jira/browse/SOLR-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221782#comment-15221782
]
Mark Miller commented on SOLR-8830:
-----------------------------------
1) I think it's reasonable. You arguments make sense to me.
2) I think we should be sure errors are always propagated correctly when Solr
is using an internal SolrJ client.
3) I think this is a great start. We can open a new JIRA if we want to pursue
this more.
> 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
> Attachments: SOLR-8830.patch
>
>
> 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]
