-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Message publishing via Sink and OutputDestination times out with Spring Integration 6.3.2 #9362
Comments
Apparently the fix in Spring integration
What I see in the debug session, when that
And that is a race condition of the application state when this I'm thinking about reworking that |
Please, raise an issue on Spring Cloud Stream side and I'll provide PR shortly after I come up with the unit test to at least cover the functionality. Closing this one as |
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.
FYI, @wrwksexahatvani , I've raise Pull Request in Spring Cloud Stream: spring-cloud/spring-cloud-stream#2978 No need in the separate issue over there. |
In what version(s) of Spring Integration are you seeing this issue?
6.3.2.RELEASE
Describe the bug
The
DummyEventProducerIntegrationTest
t in the sample project https://github.com/andrashatvani/spring-demo/ times out once I upgrade Spring Boot to 3.3.2 in the POM. It works with Spring Boot 3.3.1 with Spring Integration 6.3.1 as it has worked so far always. @wilkinsona guided me in the direction of Spring Integration in spring-projects/spring-boot#41602.To Reproduce
Run
DummyEventProducerIntegrationTest
.Expected behavior
The test should pass.
Sample
https://github.com/andrashatvani/spring-demo/
The text was updated successfully, but these errors were encountered: