1) The queue transaction is rolled back, effectively moving the message back in front – therefore, it will be immediately retried.
After 5 failed attempts (at least that is the default), Rebus will move the message to the error queue. The default retry mechanism is intentionally very swift – this way, the input queue will never be clogged by poisonous messages.
If you need more sophisticated retries, I suggest you tage a look at bus.Defer – it can defer delivery of a message to the future. It requires that you have a timeout manager(*) running though.
2) I guess that’s what I call “error queue”, except there’s no retry 🙂
I did create a solution some time, though, where I coded a simple endpoint that would periodically empty the error queue and move all the messages back into the original source queue, as a form of crude automatic second-level retry mechanism.
3) No. NServiceBus has the concept of second-level retries, but this is something that I’ve never really needed (enough) with Rebus. But with Rebus, you’re on your own here – it should be fairly easy to do some intelligent bus.Defer that can then be easily adapted to each kind of error that you’re expecting.
4) See (3)
I hope that clarifies a bit 🙂
(*) The timeout manager can be a separate endpoint whose only job in life is to receive a message, hold on to it for a while (i.e. save it to a database), and then return it to the sender when the time has elapsed. The timeout manager can be hosted in-process though, but using the .Timeouts(t => t.???) configuration spell.
0
solved How do I specify a redelivery policy and separate retry queue processor in Rebus