Scatter Gather Blocking threads when used along with WebFlux & Netty

[sirimamilla]

Affects Version(s): 5.3

---

Scatter Gather is blocking on thread waiting for response at gatherResultChannel.receive() as this is blocking call.

Is there any alternative option to avoid waiting for response like this, instead subscribe to the response from some subscribable channel or any other alternative(not able to think of a solution) so this will work perfectly fine without holding up on threads.

I have been looking out for solutions but couldn't find any perfect one.

[artembilan]

Consider to make an inputChannel for Scatter-Gather as an ExecutorChannel. This way you'll shift a WebFlux work to a separate thread and it won't see that blocking any more.
Kinda non-reactive solution, but we definitely can't make a Scatter-Gather as non-blocking. There is still an aggregator involved with its locking on groups for completion.

[sirimamilla]

Hi @artembilan,

Similar to the way, we have WebFlux as an alternative to Http, can we consider a new Scatter Gather that can be reactive or something like that. Just a thought.

Aggregator Groups doesnt hold threads. so they will work perfectly with Reactive framework.

[artembilan]

Yeah... That has crossed my mind as well. We have already a https://github.com/spring-projects/spring-integration/blob/master/spring-integration-core/src/main/java/org/springframework/integration/aggregator/FluxAggregatorMessageHandler.java, so it definitely possible to take a look into reactive scatter-gather implementation...

[sirimamilla]

Hi @artembilan,

My further tests bumped me into Gateway also behaving the same way, where it blocks the reactor threads and is causing the effect of reactive framework to not be fully utilized.

Message<?> gatherResult = gatherResultChannel.receive(this.gatherTimeout); is the one blocking the thread.

The problem with all of these patterns is common, we are making the parent thread wait, for executor channels to complete the request execution rather than handing the monitoring for response to some monitor thread(Just a thought).

[artembilan]

To make a gateway reactive or non-blocking, you need to consider to have a specific return type on the gateway method.
See docs for more info: https://docs.spring.io/spring-integration/docs/5.2.3.RELEASE/reference/html/messaging-endpoints.html#async-gateway

we are making the parent thread wait

That's really the point of those components. We don't advertise that Spring Integration is fully reactive & non-blocking.
We just need to deal with some workarounds for reactive programming how to call blocking code or develop reactive alternatives. And this is indeed what we are pursuing with issues similar to this.

[artembilan]

The ScatterGatherHandler extends AbstractReplyProducingMessageHandler which provides us option like this:

	/**
	 * Allow async replies. If the handler reply is a {@link CompletableFuture} or {@link Publisher},
	 * send the output when it is satisfied rather than sending the future as the result.
	 * Ignored for return types other than {@link CompletableFuture} or {@link Publisher}.
	 * @param async true to allow.
	 * @since 4.3
	 */
	public final void setAsync(boolean async) {

So, we definitely need to take that into account and allow to make that:

Message<?> gatherResult = gatherResultChannel.receive(this.gatherTimeout);

as non-blocking.

Sorry for delay and thank you for the patience!
We might even consider to back-port the fix into 6.5.x.