Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove redundant
delaySubscription
from FunctionConfiguration
Related to: spring-projects/spring-integration#9362 After the fix in Spring Integration: spring-projects/spring-integration@bdcb856 we ended up in a deadlock situation with a `beginPublishingTrigger` in the `FunctionConfiguration` used for the `delaySubscription()` on an original `Publisher`. The `FluxMessageChannel` uses its own `delaySubscription()` until the channel has its subscribers. Apparently the logic before was with errors, so the `FluxMessageChannel` was marked as active even if its subscriber is not ready yet, leading to famous `Dispatcher does not have subscribers` error. So, looks like this `beginPublishingTrigger` was introduced back in days in Spring Cloud Stream to mitigate that situation until we really emit a `BindingCreatedEvent`. The deadlock (and the flaw, respectively) is with the `setupBindingTrigger()` method implementation where `FluxMessageChannel` now "really" delays a subscription to the provided `Publisher`, therefore not triggering that `Mono.create()` fulfilment immediately. The `BindingCreatedEvent` arrives earlier, than we have a subscriber on the channel, but `triggerRef.get()` is `null`, so we don't `success()` it and in the end don't subscribe to an original `Publisher` since `delaySubscription()` on it is never completed. Since `FunctionConfiguration` fully relies on `IntegrationFlow.from(Publisher)`, which ends up with the mentioned `FluxMessageChannel.subscribeTo()` and its own `delaySubscription()` (which, in turn, apparently fixed now), we don't need our own `delaySubscription()` any more. Therefore the fix in this PR is to propose to remove `beginPublishingTrigger` logic altogether.
- Loading branch information