You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Resolves#2457
Previously, classifying `RuntimeException` either for no retries or for
blocking retries would cause undesirable effects - its classification
would be found first because the classifier first traverses up the
class hierarchy to find a match before traversing down the cause links.
When classifying exception for retry, unwrap the 'LEFE' cause from a
`TimestampedException` and/or `ListenerExecutionFailedException` so
that the classification is made on that cause.
By default, the retry classifier has no classified exceptions when
used in "classify for retry" mode (instead of the default "classify
for no retry" mode). This means that, if `retryOn(RuntimeException.class)`
is used, then all `RuntimeException`s will be retried (including those
that are usually considered fatal).
With mixed blocking/non-blocking retries, change the behavior to include
the standard fatal exceptions in case the user configures all `RuntimeException`s
to use blocking retries.
Also tested with a Boot app to see that a conversion exception bypasses
all retries and goes straight to the DLT.
Copy file name to clipboardExpand all lines: spring-kafka/src/test/java/org/springframework/kafka/retrytopic/ListenerContainerFactoryConfigurerTests.java
0 commit comments