Retry Policies

If you use message brokers (Kafka, RabbitMQ, etc.) you might have error queues. When your system being insufficient you might get transient errors and you get errors in your queue. Then you have to move them manually. If you’re getting a lot of transient errors your night might be a nightmare.

When a customer doing some operation she/he can’t wait until morning. If you want to solve this kind of error completely, you can make better your system (cloud solutions, etc.) If you can’t change your system, you can try different solutions. You can try to retry policies. I wrote this example for MassTransit and RabbitMQ but I think this solution might be possible for different message brokers too. You can search.

If you have no idea about message brokers, you can read this article.

Retry policy checks your consumer before sending a message to the error queue. We suppose you have no retry policy. When you get an error in your consumer your message sends to the error queue.

Retry Policies for MassTransit

• None: No retry
• Immediate: Retry immediately, up to the retry limit
• Interval: Retry after a fixed delay, up to the retry limit. It has two parameters. RetyCount is the number of retry attempts. Interval parameter can be an int value or TimeSpan.
• Intervals: Retry after a delay, for each interval specified. You can specify the Interval rule with this.

I made an example of this. I’m trying to consume messages at different times. I wrote a method for generating different TimeSpan values. It’s generating different values. It’s consuming messages at different times because I thought I can reduce the message density.

It’s a simple solution. It’ll reduce your error queue count but when you increase retry count or intervals, the processing time of queues might be longer. You can read all configuration settings from here. Also, you can review the repository.

This method is generating different timespan values.

This method is so simple. It just makes unique values.

Configuration on Startup file

I added an Exception to MembershipStartedEventConsumer.cs. I suppose you already see the repository. I think you know when a post request sends to MembershipController post method, it’ll publish an event and the consumer is trying to consume the message.

You can see consume times here:

t0: DateTime: 4/12/2021 10:12:58 PM

t1: DateTime: 4/12/2021 10:13:04 PM

t2: DateTime: 4/12/2021 10:13:08 PM

t3: DateTime: 4/12/2021 10:13:15 PM

The message will move to the error queue when it can’t consume. But when you get any transient error it might consume in second or third retry.

Also, you can review this diagram to understand the difference between using a retry policy or not.

I hope it might be helpful)