Fatal exceptions in Combining Blocking and Non-Blocking Retries

[jgslima]

Documentation reference: link.

"In combination with the global retryable topic’s fatal exceptions classification, you can configure the framework for any behavior you’d like, such as having some exceptions trigger both blocking and non-blocking retries, trigger only one kind or the other, or go straight to the DLT without retries of any kind."

I was not able to understand how to configure something like this:

• activate blocking retries for exceptions of type RuntimeException (which I have done by making blockingRetries.retryOn(RuntimeException.class));
• but configuring some specific sub-classes of RuntimeException to go directly do DLT. For that, I tried to add them in manageNonBlockingFatalExceptions().

But, as far as I can verify here, exceptions added to manageNonBlockingFatalExceptions(), are used to skip just the "non blocking" retries, not the blocking ones. For example, when just making blockingRetries.retryOn(RuntimeException.class) if the listener throws a MessageConversionException (which is a pre-defined fatal exception) it goes through the blocking retries (and after that, it correctly skips the non blocking retries). This is not in accordance to the example code of the documentation, in regard to ShouldSkipBothRetriesException.

Also, I think the documentation above is a bit confusing. In the code example "Here’s an example with both configurations working together:", I do not understand how the behaviour for ShouldRetryOnlyBlockingException and ShouldRetryViaBothException would be different, because both are just being passed in blockingRetries.retryOn().

Thank you.

[garyrussell]

RuntimeException is too general here; the exception classifier for the retryable topic, by default, retries no exceptions (ExceptionClassifier.defaultFalse()) so that all exceptions go through the non-blocking retry chain (or straight to the DLT, depending on the type).

Since RuntimeException is a super class for many exceptions, they will all be retried blocking, before going through the retry chain.

You need to be more specific with the exception type(s) that you want to try in a blocking fashion.

We could look at adding some mechanism to handle this use case but, in the meantime, use narrower exception types for blocking.

[garyrussell]

Correction, RuntimeException will always be found first because the exception classifier goes up the class hierarchy before traversing the causes to find a match.

[garyrussell]

I have found a solution.

[jgslima]

Thank you for the attention.
Idea here is to configure RuntimeException to have blocking retries in order to try to avoid passing through the retry topic chain for issues that are very ephemeral (like an external system or component being offline for a short amount of time). So in my opinion, in the development phase of a system, it is easier and safer to configure RuntimeException and then to specify specific ones to be ignored, because in the worst case, I prefer the mechanism to block with some Exceptions that would not be needed than the opposite (do not block for exceptions that are worth it). And it would be hard to list all the possible Exceptions that may mean connection issues with all the external components.
Indeed, because of that I am willing to just leave the RuntimeException. If something is done in the framework about that, great, but currently it suits me.

[garyrussell]

This is now fixed on main (upcoming 3.0 release). I am not comfortable back porting it because it might (although probably will not) involve a behavior change for some users.

#2458

Having worked on your other discussion, I think I might have a work around for 2.9.