On 14/12/2022 11:21, Rémy Maucherat wrote:
On Mon, Dec 12, 2022 at 4:43 PM <ma...@apache.org> wrote:
<snip/>
+ /** + * {@inheritDoc} + * <p> + * If this method is called when the output stream is in non-blocking mode, it will immediately return with the stream + * effectively closed, even if the stream contains buffered data that is yet to be written to client. The container will + * write this data out in the background. If this process fails the {@link WriteListener#onError(Throwable)} method will + * be invoked as normal. + */ + @Override + public void close() throws IOException { + super.close(); + }
<snip/>
diff --git a/java/org/apache/coyote/http11/Http11OutputBuffer.java b/java/org/apache/coyote/http11/Http11OutputBuffer.java index cf666b605d..570b90c0d7 100644 --- a/java/org/apache/coyote/http11/Http11OutputBuffer.java +++ b/java/org/apache/coyote/http11/Http11OutputBuffer.java @@ -565,6 +565,13 @@ public class Http11OutputBuffer implements HttpOutputBuffer { @Override public void end() throws IOException { + /* + * TODO + * As of Servlet 6.1, this flush is (currently) meant to be + * non-blocking if the output stream is in non-blocking mode. That + * requirement creates various complications I want to discuss with + * the EG before I try implementing it. + */ socketWrapper.flush(true); }Ok there are the main points: - Flushing shouldn't be used at all in non blocking, since data will always be sent ASAP. So if you flush in the app, then it will have to break the API promise (not blocking). Overall, if flush is allowed to be called in non blocking, then it should be a noop instead since it will never do anything useful (if the app wants to know when writing is done, then it should wait for the notification). - If (I think that's the case here) the app server blocks to wait for the end of the request without anything from the app on the call stack, then it possibly degrades scalability a bit but it's not actually going to be a problem in the real world.
That comment is there due to the clarification added to ServletOutputStream.close().
I have a patch that might work for the clarified close behaviour but I need to find some time to write some test cases to check it. If it doesn't work out, the current behaviour seems reasonable to me although I'll probably go back tot he EG to discuss options.
Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
