[
https://issues.apache.org/jira/browse/SOLR-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934354#comment-17934354
]
David Smiley commented on SOLR-17562:
-------------------------------------
This was merged; shouldn't the issue be closed against the corresponding
release [~gerlowskija]
In retrospect having looked at the changes here and thinking about Jackson, I'm
inclined to propose something different. It's the job of the ResponseParser to
parse the response (obviously). InputStreamResponseParser is a *very* special
response parser that I don't think should be used unless you _need_ to process
the response _after_ the SolrClient.request method returns. It came into
existence with streaming expressions, which makes sense as you have this stream
that outlives the request method. Note that InputStreamResponseParser
short-circuits lots of error checking that the Http SolrClients do, thus
putting the responsibility of the user of InputStreamResponser to do (or forget
to do) that. We could have a general JacksonResponseParser, instantiated with
a Class instance to tell Jackson what Java class to instantiate based on the
JSON. Then this gets placed onto a holder NamedList as "response" to satisfy
the ResponseParser contract. Use of Map would mean to basically replicate
JsonMapResponseParser functionally. Not using the special
InputStreamResponseParser means SolrClient's error handling would work if the
server returns an error instead of the intended object. JacksonParsingResponse
(that which implements SolrResponse) would not exist; the SolrResponse is to
hold the response, not to parse it. I suppose a subclass of SimpleSolrResponse
that trivially returns the "response" value as the expected type via a
getParsed method would be used instead.
> Unify v2 API streaming support
> ------------------------------
>
> Key: SOLR-17562
> URL: https://issues.apache.org/jira/browse/SOLR-17562
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Several v2 APIs return raw files or streams of data, including:
> {{ZooKeeperReadAPI}}, {{NodeFileStore}}, and {{CoreReplication.fetchFile}}.
> But the APIs vary slightly in how they support this: ZooKeeperReadAPI uses
> the deprecated "ContentStream" with "RawResponseWriter", NodeFileStore
> directly attaches a "SolrCore.RawWriter" to the underlying SolrQueryResponse,
> and CoreReplication follows the JAX-RS best practice of using the
> "StreamingOutput" interface.
> This ticket aims to align all of these approaches and document our approach
> in {{dev-docs/apis.adoc}} or a similar file.
> The preferred approach ([see discussion
> here|https://github.com/apache/solr/pull/2734]) at the time of writing is to
> use StreamingOutput. If this doesn't change, this ticket will need to:
> * modify our Java codegen template and related code to support this new
> response type. (Java codegen currently requires that all responses subclass
> SolrJerseyResponse)
> * remove the "x-omitFromCodegen" tag from any APIs using StreamingOutput (see
> ReplicationApis.fetchFile for an example)
> * Switch other raw-file/streaming APIs over to using StreamingOutput.
> Validate v1 and v2 responses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
