-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix pub/sub subscription order on dynamic flows #3003
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
Milestone
Comments
garyrussell
added a commit
to garyrussell/spring-integration
that referenced
this issue
Jul 24, 2019
Fixes spring-projects#3003 Statically defined flows with a publish/subscribe channel invoke the subscriptions in natural (declared) order. The components in the flow are started by the application context in phases (consumers, then producers) and bean declaration order within each phase. When a dynamically declared flow is started, the components are started by the `StandardIntegrationFlow` in reverse order (last to first) so that we don't start producing messages before the flow is fully wired. This has the side-effect that pub/sub subscribers are invoked in an unnatural (last to first) order. All subscription sub-flows start with a bridge from the pub/sub channel to the first component's input channel. The `BroadcastingDispatcher` honors the `Ordered` interface. Change the `PublishSubscribeSpec` to set the `order` property so that subscribers are always invoked in the natural order, regardless of whether the flow is statically or dynamically defined.
garyrussell
added a commit
to garyrussell/spring-integration
that referenced
this issue
Jul 24, 2019
Fixes spring-projects#3003 Statically defined flows with a publish/subscribe channel invoke the subscriptions in natural (declared) order. The components in the flow are started by the application context in phases (consumers, then producers) and bean declaration order within each phase. When a dynamically declared flow is started, the components are started by the `StandardIntegrationFlow` in reverse order (last to first) so that we don't start producing messages before the flow is fully wired. This has the side-effect that pub/sub subscribers are invoked in an unnatural (last to first) order. All subscription sub-flows start with a bridge from the pub/sub channel to the first component's input channel. The `BroadcastingDispatcher` honors the `Ordered` interface. Change the `PublishSubscribeSpec` to set the `order` property so that subscribers are always invoked in the natural order, regardless of whether the flow is statically or dynamically defined.
artembilan
pushed a commit
that referenced
this issue
Jul 27, 2019
Fixes #3003 Statically defined flows with a publish/subscribe channel invoke the subscriptions in natural (declared) order. The components in the flow are started by the application context in phases (consumers, then producers) and bean declaration order within each phase. When a dynamically declared flow is started, the components are started by the `StandardIntegrationFlow` in reverse order (last to first) so that we don't start producing messages before the flow is fully wired. This has the side-effect that pub/sub subscribers are invoked in an unnatural (last to first) order. All subscription sub-flows start with a bridge from the pub/sub channel to the first component's input channel. The `BroadcastingDispatcher` honors the `Ordered` interface. Change the `PublishSubscribeSpec` to set the `order` property so that subscribers are always invoked in the natural order, regardless of whether the flow is statically or dynamically defined.
garyrussell
added a commit
that referenced
this issue
Jul 29, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://stackoverflow.com/questions/56985297/possible-issue-with-publish-subscribe-channel/56990237#comment100856240_56990237
Since dynamic flows are started in reverse, pubsub subscriptions are started in a non-intuitive order.
The text was updated successfully, but these errors were encountered: