CODEWITHSUNDEEP
nservicebus
Rosdi Kasim
Rosdi Kasim

Reputation: 26036

How to tell NServiceBus to retry a message?

I have a process whereby an admin must be alerted and the message automatically retried if some business logic is not meet.

Currently what I did is I throw and Exception to force NServiceBus to retry the message.

I have a feeling this is not what I am supposed to do. Is this the proper way of doing it?

public void Handle(ImportantCmd message)
{
    //do some awesome business logic here
    ..a business logic is not meet..

    //send email alert in case of error
    Bus.Publish<SendEmailCmd>(email =>
    {
        email.To = "[email protected]";
        email.Title = "Important title";
        email.Body = "Important message";
     });

    //then force NServiceBus to retry
    throw new Exception("Blah blah...., retrying this message.");
 }

Update: I would like an admin to be alerted whenever some condition is not met and he/she should be able to see all messages that are affected (perhaps in a dedicated queue?) and possibly retry them.

Basically our service depends on an external service. This external service occasionally could return erroneous respond (but if we retry it might work). That is why I am alerting the admin and at the same time retrying them.

Upvotes: 0

Views: 2272

Answers (2)

Sean Farmar
Sean Farmar

Reputation: 2293

Given your update (i'm assuming the admin will not alter the message) i would say you can use the FLR (First Level retry) and SLR(Second Level Retry) to retry the messages as the web service you are calling will eventually be able to process your message.

If that fails, the message will end up in the error queue.

You can monitor the error queue, by polling ServiceControl using it's API (if you use the platform installer it will install ServiceControl with NServiceBus) or subscribing to the MessageFailed event ServiceControl is publishing like this spike code more on David's blog .

Here is a link about SLR

Check Out David's book

Upvotes: 2

David Boike
David Boike

Reputation: 18645

The retry mechanism of NServiceBus (driven by throwing an exception) is supposed to be for infrastructure problems (deadlocks, servers unavailable, outright bugs, etc.) that a developer would need to look at. That way transient failures (deadlocks, web service down) is taken care of on an automatic retry, and permanent errors (whoops looks like I divided by zero!) go to an error queue for a developer to figure out and take administrative action.

Now, if your endpoint is transactional, your code above will not work as expected because either everything in the message handler is in the transaction. That means if you throw an exception, your Bus.Publish (or Bus.Send, and you can't/shouldn't publish a command) will not actually happen.

Really, I don't understand what sort of business logic would require an alert and a retry. Can you elaborate? What is it that makes your business logic so non-deterministic based on the incoming message? And can anything be done about that?

But at the end of the day, this business logic sounds like it's part of a business process, which should stay expressed in messages, not in errors and retry. So if a condition means you need to notify someone and so something else, publish a ThingHappened event (a subscriber can send an email) and then have another handler do whatever is necessary to handle that business process. If that means that, in the future, a new command comes through with largely the same data, then so be it.

Upvotes: 2

Related Questions