Due to race condition between this.sink.tryEmitNext() and this.sink.emitComplete(), there could be a situation when onNext signal slips after onComplete. Appears on fast producers into this FluxMessageChannel.
The error in logs looks like:
2025-02-26 17:39:51,315 WARN [main] [org.springframework.beans.factory.support.DisposableBeanAdapter] - Invocation of destroy method failed on bean with name 'org.springframework.integration.channel.FluxMessageChannel'
reactor.core.publisher.Sinks$EmissionException: Spec. Rule 1.3 - onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially.
at reactor.core.publisher.InternalManySink.emitComplete(InternalManySink.java:86) ~[reactor-core-3.7.3.jar:3.7.3]
at org.springframework.integration.channel.FluxMessageChannel.destroy(FluxMessageChannel.java:174) ~[classes/:?]
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:211) ~[spring-beans-6.2.3.jar:6.2.3]
Right, the DisposableBeanAdapter hides an exception behind the warn message, but calling FluxMessageChannel.destroy() may lead to failures in the target application.
For example, when beans are destroyed manually, not via BeanFactory.
Due to race condition between
this.sink.tryEmitNext()andthis.sink.emitComplete(), there could be a situation whenonNextsignal slips afteronComplete. Appears on fast producers into thisFluxMessageChannel.The error in logs looks like:
Right, the
DisposableBeanAdapterhides an exception behind the warn message, but callingFluxMessageChannel.destroy()may lead to failures in the target application.For example, when beans are destroyed manually, not via
BeanFactory.