As far as I know if a message delivery fails then NServiceBus retries
immediately and keeps doing this until 5th attempt in a row fails. If
that happens then it sends the message to the error queue. Is there
any setting that would instruct NServiceBus to wait some period of
time between retries? Is there any other built-in way of handling such
cases when the first delivery fails?
As far as I know if a message delivery fails then NServiceBus retries immediately and keeps doing this until 5th attempt in a row fails. If that happens then...
The retry count doesn't have to do with message delivery. MSMQ handles that independently of nServiceBus. When a transaction is thrown during any part of...
Isn't Pawel asking about some kind of "Retry strategy". The current one is "Retry 5 time with no wait". I've seen solutions that sleeps a while before retrying...
My answer was to say that nServiceBus currently doesn’t do those kinds of retry strategies – MSMQ does that by itself. That’s one example as to a case...
Hi, If I understand correctly then whenever a message is sent using MSMQ we deal with 3 distinct steps. 1. The message is sent to the sender local queue. 2....
Actually, when you send a message, it first goes to the outgoing queue on the sending machine. Once that successfully occurs, the sending thread is released to...
I see your point and it makes sense as long as you control external systems. If you don't and they are a bit flaky than a good retry strategy might help a lot....
In the example I was talking about, what do you view as the external system? Or does the fact that I assume MSMQ communication lead you to that conclusion? -- ...
I don't understand why retry handling would need to be part of the framework? If you wanted to do that, couldn't you just do something like (prototype code): ...
That’s an interesting thought – using nServiceBus under the ITransport level to implement that functionality. It would break configuration based on type,...
I'd rather not have to define an IReplayableMessage interface to do something like that, but you have to store the replay information somewhere. You could do...
I’d vote for exposing custom headers as well, somewhere to put and retrieve info that is needed by the messaging system and not by the domain. From:...
Currently there’s TransportMessage which sits on the boundary between the bus and the transport, exposing to the bus in a technology agnostic way the...
I'm not referring to a transport specific header. Basically, I just want an IDictionary<string, string> property called Headers on TransportMessage and a way...
There is always this question where you draw the line between application code and infrastructure code. In this particular case I would see the retry strategy...
By the external system I mean a system that the service needs to talk to synchronously when it processes a message. As an example, there is a system that uses...
Now I understand what your scenario is! The way that external integration of that kind is handled is simple: Your application logic sits in one autonomous...
From my perspective this is like adding another level of indirection. At the end of the day there must be a piece of code that handles retries and it does not...
Just keep in mind what happens to that state (the number of retries) when your server restarts. Maybe the answer is “I don’t care, I’ll just start from...
Putting retry strategy at the level of infrastructure doesn't mean that I want to keep the number of retires in memory. It can be serialized together with the ...
Offline 
Send Email