Rebs handler doesnt retry when exception is thrown

Question

I'm using rebus 3.1.5 with rebus.rabbitmq 3.0.0, and rabbitmq.client 4.1.1. I have configured to use simple retry strategy with 2 max delivery attempts. I would like to retry the message in case when an exception is thrown. I don't use the transaction scope. But when an exception is thrown I don't get the message re-delivered again(it is not even in the error queue)

If this is not possible and if I need to configure rebus with HandleMessagesInsideTransactionScope, does it going to put locks my database until I complete the handler work?

thank you very much!

EDIT: This is what the handler looks like:

public Task Handle(SetCreditInfoCommand command) 
{
    return Task.Run(() => {
        var loanApplication = _loanApplicationRepository.Get(command.LoanApplicationId); 
        try { 
            //something that throws an exception here
        }
        catch(Exception ex)
        {
            throw ex;
        }
    });
}

and this is how the bus is configured:

var bus = Configure.With(adapter)
    .Transport(t => t.UseRabbitMq(connectionString, queueName))
    .Options(b => b.SimpleRetryStrategy(
            maxDeliveryAttempts: 2,
            secondLevelRetriesEnabled: true, 
            errorQueueAddress: queueName + "_error"
    ))
    .Timeouts(t => t.StoreInSqlServer(dbConnection, "RebusTimeouts", false))
    .Start();

IoC.GetContainerBuilder().RegisterInstance(bus).As<IBus>();

mookid8000 · Accepted Answer · 2017-12-13T15:44:45.980

1

I don't use the transaction scope

~~Good – the transaction scope is only there if you want to group multiple bus operations together OUTSIDE of a Rebus handler, e.g. when handling a web request.~~

Everything that happens in a Rebus handler is automatically grouped together and committed as part of the transaction context that spans the handling of the incoming message.

EDIT: The question author meant System.Trasactions.TransactionScope, which Rebus can automatically apply to message handlers by using the Rebus.TransactionScopes package.

I originally thought it was RebusTransactionScope, which is Rebus' own scope for managing its own messaging transaction.

when an exception is thrown I don't get the message re-delivered again(it is not even in the error queue)

This sounds weird. Do you let the exception bubble out of the message handler?

I added the code from your comments to your question – it's much easier to read it that way :)

First off, I suggest you simplify your code by using the async keyword in the method declaration like this:

public async Task Handle(SetCreditInfoCommand command) 
{
    // (...)
}

Next, I recommend you do now throw ex, because that's not a proper rethrow – it will ruin the stack trace of the ex exception.

You should

catch(Exception ex)
{
    throw;
}

if you absolutely want to catch the exception. But I really recommend that you do NOT catch exceptions in your Rebus handlers, unless you want to do something with them – in this case, it looks to me like your handler would be better off like this:

public async Task Handle(SetCreditInfoCommand command) 
{
    var loanApplication = _loanApplicationRepository.Get(command.LoanApplicationId); 

    //something that throws an exception here
}

because it's much clearer.

The second level retries are working fine but the immediate retries are not working

So it looks like Rebus jumps directly to 2nd level retries? Can you tell me more about how you figured that out?

edited Dec 13 '17 at 15:44

answered Dec 13 '17 at 13:30

mookid8000

18,258
2
39
63

public Task Handle(SetCreditInfoCommand command) { return Task.Run(() => { var loanApplication = _loanApplicationRepository.Get(command.LoanApplicationId); try { //something that throws an exception here } catch(Exception ex){ throw ex; } }); } this is how my hand;er looks like – Chathuri Gunawardhana Dec 13 '17 at 13:37
var bus = Configure.With(adapter) .Transport(t => t.UseRabbitMq(connectionString, queueName)) .Options(b => { b.SimpleRetryStrategy(maxDeliveryAttempts: 2, secondLevelRetriesEnabled: true, errorQueueAddress: queueName + "_error"); }) .Timeouts(t => t.StoreInSqlServer(dbConnection, "RebusTimeouts", false)) .Start(); IoC.GetContainerBuilder().RegisterInstance(bus).As(); – Chathuri Gunawardhana Dec 13 '17 at 13:42
Above is my bus configuration. The second level retries are working fine but the immediate retries are not working – Chathuri Gunawardhana Dec 13 '17 at 13:43
var header = new Dictionary {{"attempt_no", (deliveryAttempts + 1).ToString()}}; _bus.Defer(timeForNextTry, message, header).Wait(); I have another handler that uses second level retries when an exception is thrown(I call the above piece of code inside the catch block). But the handler get triggered after specified waiting time. – Chathuri Gunawardhana Dec 13 '17 at 14:11
I just tried adding the transaction scope now. Then the immediate retries were working fine. Am I using the wrong version of rebus or something? – Chathuri Gunawardhana Dec 13 '17 at 14:33
What do you mean by "adding the transaction scope"? And no, Rebus 3.1.5 should work just fine... – mookid8000 Dec 13 '17 at 14:48
By adding HandleMessagesInsideTransactionScope(); inside options in the rebus configuration – Chathuri Gunawardhana Dec 13 '17 at 15:04
That sounds pretty weird. `HandleMessagesInsideTransactionScope()` comes from the [Rebus.TransactionScopes](https://www.nuget.org/packages/Rebus.TransactionScopes/) package, which works by executing handlers inside a `System.Transactions.TransactionScope`. Could you try and replace your logic (which I assume carries out some database logic or something like that) with a one-liner that simply throws an exception? – mookid8000 Dec 13 '17 at 15:08
when I have only one line which is throwing exception, then the immediate retries are working. Can't figure out why? (for the database operations I'm using mssql with entity framework) – Chathuri Gunawardhana Dec 13 '17 at 15:24
my guess is that there is some kind of issue with how Entity Framework behaves in your code – I suggest you take a look at how you manage your unit of work, or simply use transaction scopes (like you do now) to manage it – mookid8000 Dec 13 '17 at 15:32
Thank you very much for the help! – Chathuri Gunawardhana Dec 13 '17 at 15:40

Rebs handler doesnt retry when exception is thrown

1 Answers1