[
https://issues.apache.org/jira/browse/SOLR-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18063581#comment-18063581
]
ASF subversion and git services commented on SOLR-17549:
--------------------------------------------------------
Commit d977d7eac6f8785b7a4a7595fd94f33df46185ee in solr's branch
refs/heads/branch_10x from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=d977d7eac6f ]
SOLR-17549: v2 SolrRequest/SolrResponse should throw exception on error (#4183)
This commit updates our v2 SolrJ code to throw RemoteSolrException when
error-responses are encountered.
It relies on a pre-existing attempt at error detection already present in our
SolrClient implementations. Code in many of our clients already attempts to
detect these errors by looking for a 'NamedList' key, "error", which it
(incorrectly) assumed would be present in the v2 case but which isn't
populated by the ResponseParser that our v2 SolrRequest/SolrResponse
implementations use by default.
This commit updates JacksonDatabindResponseParser to populate this
"error" key that SolrClient's were looking for, which in turn enables the
clients to correctly throw RemoteSolrException in these cases.
> Reconsider error-handling in generated-v2 SolrResponses
> -------------------------------------------------------
>
> Key: SOLR-17549
> URL: https://issues.apache.org/jira/browse/SOLR-17549
> Project: Solr
> Issue Type: Bug
> Components: SolrJ, v2 API
> Affects Versions: 10.0
> Reporter: Jason Gerlowski
> Priority: Blocker
> Labels: V2, pull-request-available
> Fix For: 10.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In most cases upon receiving an HTTP response, SolrClients will immediately
> parse it into a NamedList and then inspect that NamedList to see whether a
> client-side exception should be triggered.
> Our generated v2-API SolrRequest/SolrResponse classes work differently. They
> never convert the response into a NamedList, instead using Jackson to put it
> into a strongly-typed POJO. -Additionally, response parsing occurs lazily -
> typically not until after the SolrResponse has been returned to callers and
> they've invoked a special "getParsed()" method.-
> The combined effect of these two differences is that all of the
> error-detection/exception-throwing code in SolrClient is skipped when making
> generated-v2 requests! Callers can still detect errors by manually
> inspecting their response POJOs, but anyone expecting SolrJ's "no exception
> means success" convention are in for a frustrating shock.
> We should change how response-parsing happens in the generated-v2 case to
> match the rest of SolrJ. (Or alternately - investigate some more intuitive
> way to communicate failure.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
