Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Conditional failover in Direct Channel - Introduce Predicate<Exception> failoverStrategy into DirectChannel and its UnicastingDispatcher ( and in ExecutorChannel if possible) #8981

Closed
LukePawlak opened this issue Mar 8, 2024 · 0 comments · Fixed by #8982
Closed

Conditional failover in Direct Channel - Introduce Predicate<Exception> failoverStrategy into DirectChannel and its UnicastingDispatcher ( and in ExecutorChannel if possible) #8981

LukePawlak opened this issue Mar 8, 2024 · 0 comments · Fixed by #8982
Labels
in: core type: enhancement
Milestone
6.3.0-M2

Comments

@LukePawlak
Copy link

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.
@LukePawlak LukePawlak added status: waiting-for-triage The issue need to be evaluated and its future decided type: enhancement labels Mar 8, 2024
@artembilan artembilan added this to the 6.3.0-M2 milestone Mar 8, 2024
@artembilan artembilan added in: core and removed status: waiting-for-triage The issue need to be evaluated and its future decided labels Mar 8, 2024
artembilan added a commit to artembilan/spring-integration that referenced this issue Mar 8, 2024
@artembilan
spring-projectsGH-8981: Add UnicastingDispatcher.failoverStrategy o…
02ac57b 
…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 artembilan mentioned this issue Mar 8, 2024
Merged
artembilan added a commit to artembilan/spring-integration that referenced this issue Mar 8, 2024
@artembilan
spring-projectsGH-8981: Add UnicastingDispatcher.failoverStrategy o…
fbe6c34 
…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
@artembilan
GH-8981: Add UnicastingDispatcher.failoverStrategy option
ffe3605 
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
Assignees
No one assigned
Labels
in: core type: enhancement
Projects
None yet
Milestone
6.3.0-M2
Development

Successfully merging a pull request may close this issue.

GH-8981: Add UnicastingDispatcher.failoverStrategy option artembilan/spring-integration
2 participants
@artembilan @LukePawlak