[
https://issues.apache.org/jira/browse/SOLR-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-8830:
----------------------------------
Attachment: SOLR-8830.patch
Might've been going down the wrong path before. I realized that it's really
the SolrClient that handles and passes along the remote-error, and a few tweaks
to ConcurrentUpdateSolrClient go a long way to improving the usefulness of the
error message in the example Hoss pointed out in the description.
With the attached patch, the response body when a request is sent to the
non-leader now looks like:
{code}
{
"responseHeader":{
"status":400,
"QTime":99},
"error":{
"metadata":[
"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_shard2_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_shard2_replica1%2F&wt=javabin&version=2
Full Error
{responseHeader={status=400,QTime=45},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}}",
"code":400}}
{code}
That said, I've got a few questions before this can really be moved forward:
1.) Is this a reasonable error message? There's a decent amount of
duplication, which sucks. But I could see an argument made that including the
remote-error verbatim is the best thing we could do here. (Greatly reduces the
chance anything is being dropped, gives users the most info to debug off of,
etc.) An alternate approach would involve parsing out the root-cause from any
remote errors, but I'd guess that this would be brittle/error-prone, and would
result in some cryptic/uninformative messages. Anyone have thoughts/opinions?
2.) Assuming we decide on the right way to tweak these messages, is this
something we want to push into all SolrClient implementations, or only the ones
used directly by the /update code?
3.) The description and early comments laid out two options for where this JIRA
could go. We could improve the error messages. Or we could find a way to make
them consistent regardless of the node receiving the request. This patch takes
a stab at the first (easier) goal, but admittedly doesn't do anything to help
with the second objective. Do we really want to pursue the latter goal? If
the error-message is decent in either case, is it worth the effort to make them
consistent. (This isn't intended as a leading question; just trying to
understand the issue).
Sorry for asking (maybe) obvious questions. Just trying to make sure I'm
putting my effort in the right things here. Hope this patch is a step in the
right direction though.
> 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]
