'How to determine downstream demand from multicast sink

Is there any way to determine the minimum downstream request among subscribers to a multicast sink? With a regular FluxSink there is requestedFromDownstream() which I can use to implement backpressure, but couldn't figure out any equivalent for Sinks.Many.

I've tried scanning the inners but it doesn't seem to show downstream demand, and the closest I could find is to tryEmitNext - but it seems this may result in messages being dropped for the slow consumers and delivered to others before I detect it.

I could interpose a backpressure buffer, but I'm reading events from a file that is too large to be buffered completely, and I don't want the extra overhead of the buffer stage since the file I'm reading from is itself essentially a buffer. There is a mechanism for modulating the rate at which events are published (simulated time) which I control upstream of the sink, but in addition I want to accommodate letting subscribers catch up if they lag a bit.

Thanks..



Solution 1:[1]

FluxSink can easily provide the downstream request because there is only ever one downstream Subscriber (1 sink per subscription in eg. Flux.create).

Sinks.Many have many flavors with many downstream patterns, most of which allow multiple subscribers to a single sink instance (except with Sinks.many().unicast()).

The best option is indeed to tryEmitNext and look out for EmitResult.FAIL_OVERFLOW.

You need to pick the flavor carefully to avoid the "message is dropped for slow consumers" (I'm guessing you're trying directBestEffort()?)

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Simon Baslé