You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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`**
Copy file name to clipboardExpand all lines: spring-integration-core/src/main/java/org/springframework/integration/handler/AbstractMessageProducingHandler.java
+4-1Lines changed: 4 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -55,6 +55,7 @@
55
55
56
56
importreactor.core.publisher.Flux;
57
57
importreactor.core.publisher.Mono;
58
+
importreactor.core.scheduler.Schedulers;
58
59
59
60
/**
60
61
* The base {@link AbstractMessageHandler} implementation for the {@link MessageProducer}.
0 commit comments