Hoss Man created SOLR-8830:
------------------------------
Summary: 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]
