rstoyanchev
commented
1 month ago Indeed, when a connection is lost while writing, there is an inherent race between the Servlet container initiating error handling (to complete request handling and release resources), as well as the application trying to do the same because of the IOException it got while from writing. There was plenty of work done in the issues you found to ensure only one of these goes through because if the Servlet container error handling goes through first, the request and response objects get recycled, and if application error sneaks through as well, it may end up operating on the recycled request and response that are now by then used for a different request.
There is not much we can do to ensure which goes first, and we cannot ensure that one is preferred over the other. Once we exit the Servlet container onError notification, it assumes the error is handled. We cannot hold it up indefinitely either, and there is no guarantee the application will propagate the IOException (wrapped or not) or handle it and exit normally without further action.
In summary, you will need to be prepared to handle the root cause, which can also occur for non-streaming scenarios. We have the DisconnectedClientHelper class that may be of help in recognizing such exceptions without introducing a dependency on a Servlet container class.
mvitz
Affects: 6.1.11, 6.2.0-M7
When a
ClientAbortExceptionoccurs within a Spring MVCStreamingResponseBodysometimes the error handling is not called with the exception thrown by theStreamingResponseBody, but for the root causejava.io.IOException: Broken pipe. There seems to be a race condition, as this can be provoked reliably when throwing the exception from theStreamingResponseBodyis delayed by a few milliseconds (see test in example project). This might be only a problem for Tomcat, but I have not yet checked this.As the client aborted the connection the error handling will not be able to send anything to the client, but it can still log things or do other internal stuff. In our case this resulted in unexpected error log entries.
There are some issues that look very related (comments mention a race between Tomcat and the application), but they are closed and the issue still exists with Spring 6.2.0-M7 (I did not see something in the documentation or in a linked issue that this is a know issue for the time being; sorry if I missed it)
For the example project the expected behaviour would be that the error handling is called for the exception throws by the
StreamingResponseBody:Unexpected is that the error handling is called for the root cause