GH-8981: Add UnicastingDispatcher.failoverStrategy option
#8982
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
sobychacko
requested changes
Mar 12, 2024
| * @since 1.0.3 | ||
| */ | ||
| @RunWith(SpringJUnit4ClassRunner.class) | ||
| @ContextConfiguration | ||
| @SpringJUnitConfig | ||
| public class DispatchingChannelParserTests { |
There was a problem hiding this comment.
One general comment: since you are modifying a test, why don't we clean this up as JUnit 5 style tests? i.e - keeping the test class and the test methods with default access?
There was a problem hiding this comment.
This is not enforced style, so I leave it up personal preferences. Since this is an existing class, I wouldn’t bother removing those public words.
The new test is just a copy/paste artifact , so still no care 😅
| assertThat(counter.get()).as("each target should have been invoked").isEqualTo(3); | ||
| } | ||
|
|
||
| @Test | ||
| public void failoverStrategyRejects() { |
sobychacko
approved these changes
Mar 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #8981
Sometime the simple
boolean failoveron theMessageChannel(defaulttrue) is not enough to be sure that we can dispatch to the next handler or not. Such a decision can be made usingErrorMessageExceptionTypeRouter, but that would require an overhaul for the whole integration flowPredicate<Exception> failoverStrategyintoUnicastingDispatcherand all itsMessageChannelimplementation consumers to allow to make a decision about next failover according to a thrown exception from the currentMessageHandlerfailoverStrategyon theDirectChannel,ExecutorChannel&PartitionedChannel, and add it into respective Java DSL specsfailoverStrategyproperty from now on