Ensure AsyncListener#onError does not return until dispatch completes
#34192
Assignees
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
status: backported
An issue that has been backported to maintenance branches
type: bug
A general bug
Milestone
Comments
rstoyanchev
added
in: web
rstoyanchev
added
the
for: backport-to-6.1.x
github-actions
bot
added
status: backported
rstoyanchev
added a commit
that referenced
this issue
Jan 6, 2025
rstoyanchev
added a commit
that referenced
this issue
Jan 6, 2025
There is no need to set the DeferredResult from WebAsyncManager in an onError notification because it is already done from the Lifecycle interceptor in DeferredResult. See gh-34192
rstoyanchev
added a commit
that referenced
this issue
Jan 6, 2025
rstoyanchev
added a commit
that referenced
this issue
Jan 6, 2025
There is no need to set the DeferredResult from WebAsyncManager in an onError notification because it is already done from the Lifecycle interceptor in DeferredResult. See gh-34192
rstoyanchev
added a commit
that referenced
this issue
Jan 6, 2025
On connection loss, in a race between application thread and onError callback trying to set the DeferredResult and dispatch, the onError callback must not exit until dispatch completes. Currently, it may do so because the DeferredResult has checks to bypasses locking or even trying to dispatch if result is already set. Closes gh-34192
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a controller returns
Flux<ServerSentEvent>,SseEmitteris used to write events. If the connection drops, the write fails with IOException in a Spring MVC TaskExecutor thread while in parallel we also get a Servlet containerAsyncListener#onErrorcallback.In #32340,
WebAsyncManagerwas enhanced to be protected in this race, so only one thread can dispatch. However, it is also crucial to ensure theonErrorcallback holds up until the dispatch completes regardless of who wins.WebAsyncManager#setConcurrentResultAndDispatchguarantees this through synchronization, but when usingDeferredResult, theonErrorcallback may not call that method at all if DeferredResult error handling finds the result is already set by the competing thread. As a result, the onError callback may exit the container thread before dispatch in the Spring MVC thread compltes, which leads to the stacktrace in #33421 (comment) and also in #34188.The issue does not apply when using
Callable, e.g. viaStreamingResponseBodyas in that casesetConcurrentResultAndDispatchis always called.The text was updated successfully, but these errors were encountered: