Fix reply producing to not block reactive thread #3630
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When `DirectChannel` is used for reply producing, the data is handled on the same thread which has produced it (normally), so if we have a request-reply afterwards (e.g. `gateway()`), this thread is blocked waiting for reply. When the thread is assumed to be non-blocked (e.g. Netty event loop), the request-reply withing such a thread for the same non-blocking client causes a deadlock: the thread waits for reply, but at the same time it supposes to fulfil a synchronization barrier with that reply * Fix `AbstractMessageProducingHandler.asyncNonReactiveReply()` to use a `publishOn(Schedulers.boundedElastic())` for reply `Mono` to free producing thread from potential downstream blocking * Demonstrate deadlock with a new test in the `RSocketDslTests`; the original report was against WebFlux, but conditions are really the same: `reactor-netty` is used as a low-level client **Cherry-pick to `5.4.x`**
garyrussell
approved these changes
Sep 13, 2021
|
...and cherry-picked. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When
DirectChannelis used for reply producing, the data ishandled on the same thread which has produced it (normally), so
if we have a request-reply afterwards (e.g.
gateway()), this threadis blocked waiting for reply.
When the thread is assumed to be non-blocked (e.g. Netty event loop),
the request-reply withing such a thread for the same non-blocking client
causes a deadlock: the thread waits for reply, but at the same time it
supposes to fulfil a synchronization barrier with that reply
AbstractMessageProducingHandler.asyncNonReactiveReply()to usea
publishOn(Schedulers.boundedElastic())for replyMonoto freeproducing thread from potential downstream blocking
RSocketDslTests;the original report was against WebFlux, but conditions are really
the same:
reactor-nettyis used as a low-level clientCherry-pick to
5.4.x