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
Before sending to a DeadLetterTopic, It can be a good idea to implement a retrying policy.
This means retrying /recovering+retrying a message in case of (certain specific) exceptions.
Like a timeout of another service/api or other recoverable + retryable exception.
DLT's can be use like this with a multi-DLT arrangement. or a index can be stored of which DLT message to retry later.
Add Deadletter topic for failed message handling.
When a message get processed on a faulty manner, creating an exception, it should be published to a Dead Letter Topic for later retrying.
Backoff
Repeat then drop trying to handle message.
Start at retry after 5-50 ms (Snel opnieuw proberen)
Multiply wait time by 10
Repeat 5 times
Considerations
Order of processing messages in system could be the wrong order, due to failure in processing.
Check if Spring Kafka's DLT's handle this concurrency
or if an implementation of message offset should be stored
or if a way of redoing should be implemented (event sourcing with snapshots)
The text was updated successfully, but these errors were encountered:
FIrst!
Before sending to a DeadLetterTopic, It can be a good idea to implement a retrying policy.
This means retrying /recovering+retrying a message in case of (certain specific) exceptions.
Like a timeout of another service/api or other recoverable + retryable exception.
DLT's can be use like this with a multi-DLT arrangement. or a index can be stored of which DLT message to retry later.
Add Deadletter topic for failed message handling.
When a message get processed on a faulty manner, creating an exception, it should be published to a Dead Letter Topic for later retrying.
Backoff
Repeat then drop trying to handle message.
Considerations
Order of processing messages in system could be the wrong order, due to failure in processing.
Check if Spring Kafka's DLT's handle this concurrency
or if an implementation of message offset should be stored
or if a way of redoing should be implemented (event sourcing with snapshots)
The text was updated successfully, but these errors were encountered: