When using Mono.just or Flux.just data buffers can be allocated before subscription and consequently won't even see a cancellation signal in case the connection is closed.
The second issue is that if Mono.just or Flux.just is passed into response#writeWith those will not see a cancellation signal because cancellation is not propagated to them (i.e. can't cancel what's already been materialized).
The text was updated successfully, but these errors were encountered:
Rescheduling for 5.1.6 to confirm those are issues and confirm the preferred fix, e.g. via defer? There is probably a small chance for the things that could go wrong before those are written. Nevertheless we should address it.
Following a response on
FluxSink is respecting doOnDiscard but there is a race condition
in DataBufferUtils with file reading.
This commit makes two changes:
1) Add more checks for onDispose to detect cancellation signals
as well as to deal with potentially concurrent such signal.
2) Do not close the channel through the Flux.using callback but
rather allow the current I/O callback to take place and only then
close the channel or else the buffer is left hanging.
Despite this tests still can fail due to a suspected issue in Reactor
itself with the doOnDiscard callback for FluxSink. That's tracked under
the same issue reactor/reactor-core#1634
and for now the use of DefaultDataBufferFactory is enforced as a
workaround until the issue is resolved.
The cancellation callback in asynchronousReadFileChannel must be called
before the first read I/O or otherwise if cancellation signals happens
immediately the onDispose callback may be missed.
The DefaultBufferFactory workaround however remains in place until an
expected additional fix arrives with Reactor Core 3.2.9.