Conditional failover in Direct Channel - Introduce Predicate<Exception> failoverStrategy into DirectChannel and its UnicastingDispatcher ( and in ExecutorChannel if possible) #8981
Labels
Milestone
Comments
LukePawlak
added
status: waiting-for-triage
artembilan
added
in: core
and removed
status: waiting-for-triage
artembilan
added a commit
to artembilan/spring-integration
that referenced
this issue
Mar 8, 2024
…ption Fixes: spring-projects#8981 Sometime the simple `boolean failover` on the `MessageChannel` (default `true`) is not enough to be sure that we can dispatch to the next handler or not. Such a decision can be made using `ErrorMessageExceptionTypeRouter`, but that would require an overhaul for the whole integration flow * Introduce a simple `Predicate<Exception> failoverStrategy` into `UnicastingDispatcher` and all its `MessageChannel` implementation consumers to allow to make a decision about next failover according to a thrown exception from the current `MessageHandler` * Expose `failoverStrategy` on the `DirectChannel`, `ExecutorChannel` & `PartitionedChannel`, and add it into respective Java DSL specs * Fix involved tests to rely on the `failoverStrategy` property from now on * Document the new feature
artembilan
added a commit
to artembilan/spring-integration
that referenced
this issue
Mar 8, 2024
…ption Fixes: spring-projects#8981 Sometime the simple `boolean failover` on the `MessageChannel` (default `true`) is not enough to be sure that we can dispatch to the next handler or not. Such a decision can be made using `ErrorMessageExceptionTypeRouter`, but that would require an overhaul for the whole integration flow * Introduce a simple `Predicate<Exception> failoverStrategy` into `UnicastingDispatcher` and all its `MessageChannel` implementation consumers to allow to make a decision about next failover according to a thrown exception from the current `MessageHandler` * Expose `failoverStrategy` on the `DirectChannel`, `ExecutorChannel` & `PartitionedChannel`, and add it into respective Java DSL specs * Fix involved tests to rely on the `failoverStrategy` property from now on * Document the new feature
artembilan
added a commit
that referenced
this issue
Mar 12, 2024
Fixes: #8981 Sometime the simple `boolean failover` on the `MessageChannel` (default `true`) is not enough to be sure that we can dispatch to the next handler or not. Such a decision can be made using `ErrorMessageExceptionTypeRouter`, but that would require an overhaul for the whole integration flow * Introduce a simple `Predicate<Exception> failoverStrategy` into `UnicastingDispatcher` and all its `MessageChannel` implementation consumers to allow to make a decision about next failover according to a thrown exception from the current `MessageHandler` * Expose `failoverStrategy` on the `DirectChannel`, `ExecutorChannel` & `PartitionedChannel`, and add it into respective Java DSL specs * Fix involved tests to rely on the `failoverStrategy` property from now on * Document the new feature
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
If I use DirectChannel and subscribe to it many ServiceActivators I would like to handle error - by failover strategy on DirectChannel level - not on ErrorChannel. Reason of having many subscribes on one channel is having load balancing.
So if there will be expected Exception I could stop processing and pass it to error channel instead of passing message to other subscriber.
Example - to one Direct channel I have connected two JmsOutboundGateway - both have same logic but they are connected to different mq servers - to have load balancing.
I have request that I process in my app and if I'm sending something via JmsOutboundGateway in case of MessageTimeoutException - due to long timeout I want to stop processing whole request in my app ( timeout for whole request is short). But in case its different error for example problem with connection JmsOutboundGateway to mq I want to use other subscribers connected to different server (use failover strategy).
Current Behavior
Currently I can't do conditional failover - if something fails other subscribers will be involved. I can turn off failover in channel and build some flows with ErrorMessageExceptionTypeRouter but then I will have to implement by my own round robin and failover strategy.
Context
How has this issue affected you?
A lot of custom development.
What are you trying to accomplish?
App with high volume of request with load balancing.
What other alternatives have you considered?
Coding everything myself.
Are you aware of any workarounds?
Yes. I'd like to avoid them.
The text was updated successfully, but these errors were encountered: