Combine blocking and non-blocking error handling #2101
-
Hello 🙂 I am looking for a possibility to combine blocking and non-blocking error handling:
Now my question is: How can I configure the error handling accordingly, to use either non-blocking or blocking error handling depending on the thrown exception? How do I need to combine the configuration of RetryableTopic and DefaultErrorHandler? Thanks in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 6 replies
-
You can satisfy the first two bullets by adding retryable exceptions using the There is no support for falling back to blocking retries based on an exception. An interesting idea, but I am not sure how difficult it would be to implement. cc/ @tomazfernandes As a work around for now, you could stop the container (with the |
Beta Was this translation helpful? Give feedback.
-
That sure looks like an interesting feature, we'd be able to benefit from the best of both worlds. We already have a DefaultErrorHandler and its blocking retries setup for the retryable topics, but currently it's hardcoded with no retries and we only use its classification for not getting stuck in endless fatal exceptions loops in the DLT. By leveraging that we'd be able to execute the blocking retries before we get into the retry topics' logic. Not sure it's doable without changing some of the current classification behavior though. OTOH it should be simple enough to add new logic to the DLPRF to handle this on the retry topics' side, so we can just go that way too. |
Beta Was this translation helpful? Give feedback.
You can satisfy the first two bullets by adding retryable exceptions using the
include
andexclude
properties (or by using the.retryOn()
andnoRetryOn()
builder methods when using the configuration builder).There is no support for falling back to blocking retries based on an exception.
An interesting idea, but I am not sure how difficult it would be to implement.
cc/ @tomazfernandes
As a work around for now, you could stop the container (with the
stopImmediate
container property true).