[
https://issues.apache.org/jira/browse/SOLR-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18062259#comment-18062259
]
Jason Gerlowski commented on SOLR-17549:
----------------------------------------
Tried to write up two Options describing a "thorough" and "hacky" approach to
this problem, respectively. Curious what you guys think:
*Option 1: [Thorough] Type-parameterization in ResponseParser and
ErrorDetector-abstraction*
# Add a type-parameter to ResponseParser so that it's "processResponse" method
can return "T" instead of "NamedList<Object>"
# Create a new abstraction "ErrorDetector<T>" with a method
"detectAndThrowForRemote(T parsedResponse)"
** This is necessary because (1) above will make it so that (e.g.)
HttpSolrClientBase won't have a NamedList that it can inspect for common
error-fields, etc.
** But it's a Good Thing imo. It cuts down on response-inspection that clients
shouldn't be doing themselves. And it makes our error detection more flexible.
We have a number of APIs that don't have the nice tidy "error" field that
HSCBase is looking for (e.g. /replication?cmd=getfile, ZooKeeperReadAPI, File
Store APIs) and this allows us to handle these cleanly.
# Create a few new ErrorDetector implementations:
** "NamedListErrorDetector extends ErrorDetector<NamedList>" for v1 stuff
** "V2ErrorDetector extends ErrorDetector<SolrJerseyResponse>" for most v2 stuff
** (Optional) "StatusOnlyErrorDetector extends ErrorDetector<InputStream>" for
clients set up to use InputStreamResponseParser
# Have HSCBase and other client implementations use look up and use the right
ErrorDetector as needed.
** Not sure what'd make sense here for lookup? Should SolrRequest or
SolrResponse have a method to grab the "right" ErrorDetector for a particular
request? Or should SolrJ just have some sort of map keyed by type name that
clients pull from?
*Option 2: [Hacky] Slight Tweak to JacksonDatabindResponseParser*
HttpSolrClientBase.processErrorsAndResponses actually already has code to
detect v2 errors:
{code}
Object error = rsp == null ? null : rsp.get("error");
if (error != null && isV2Api) {
throw new RemoteSolrException(urlExceptionMessage, httpStatus, error,
true);
}
{code}
This code doesn't work, but it could *iff* JacksonDatabindResponseParser was
smart enough to set the "error" field that this code looks for. (Currently
JDRP returns a NamedList with a single key, "response", whose value is the
entire parsed SolrJerseyResponse object errors and all.)
IMO it'd be a hack to have JDRP also set the "error" field. ResponseParsers
have enough to do without failure-detection logic. But it'd only require a
tiny code change. And it'd avoid a lot of the NamedList fighting that'd come
with Option 1. And it'd be much more backport-able to boot - no changes to
public method signatures, etc.
> 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
> Fix For: 10.1
>
>
> 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]
