janhoy commented on code in PR #4574:
URL: https://github.com/apache/solr/pull/4574#discussion_r3504558602
##########
solr/core/src/java/org/apache/solr/jersey/container/JettyBridgeResponseWriter.java:
##########
@@ -58,10 +59,13 @@ public OutputStream writeResponseStatusAndHeaders(
final StatusType statusInfo = context.getStatusInfo();
httpServletResponse.setStatus(statusInfo.getStatusCode());
- if (contentLength != -1 && contentLength < Integer.MAX_VALUE) {
- httpServletResponse.setContentLength((int) contentLength);
- }
+ // Don't set Content-Length: Solr's QueryResponseWriters stream and can't
predict the exact
+ // length, so a declared value may undercount and Jetty 12.1 aborts with
"too much content
+ // written". Leaving it unset frames the response as chunked, as the v1
path already does.
Review Comment:
Claude analysis details:
solr/core/src/java/org/apache/solr/jersey/container/JettyBridgeResponseWriter.java:61-63:
if (contentLength != -1 && contentLength < Integer.MAX_VALUE) {
httpServletResponse.setContentLength((int) contentLength);
}
enableResponseBuffering() returns false (line 107), and the Solr
MessageBodyWriters don't override getSize(), so Solr can't actually know the
final length — yet Jersey's small-response buffering hands a contentLength here
that Solr sets as the header. The streamed javabin then exceeds it → 12.1
aborts → client gets EOFException reading javabin.
What should be done: stop declaring a Content-Length that Solr can't
guarantee. Since the writer streams and buffering is off, drop the
setContentLength call (or only set it when the entity is genuinely fully
buffered) and let Jetty frame the response with chunked transfer-encoding. This
mirrors what the v1 fallback already does at V2HttpCall.java:447
(response.setContentLength(-1)).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
