0

I know you can configure NServiceBus to automatically retry to send messages (FLR: First Level Retries) and wait before retrying again (SLR: Second Level Retries), but, using the default configuration (5 FLR + 5 SLR) it'll take about one minute before seeing a message into the <error> queue.

I understand the value of automatic retries, but isn't it better to fail early, configuring zero FLR pus zero SLR and actually coding expecting errors to occur ?

I mean, automatic retries goes against Fail-Fast paradigm, doesn't it ?

Machado
  • 4,090
  • 3
  • 25
  • 37
  • In some environments temporary network disconnections are routine. Automatic retries make compensation for the problem mostly transparent. It is as if the network is simply slow. – Frank Hileman Jan 12 '17 at 17:07
  • At a higher level, as the retries are attempted, you can view the operation as "in progress", not "failed" yet. At the lower level, yes it has failed, but the higher level has a different definition for failure. – Frank Hileman Jan 12 '17 at 17:10
  • @FrankHileman So, you don't think there is any advantage by running with a no-retry policy ? – Machado Jan 12 '17 at 17:52
  • No advantage whatsoever. The more retries your application can handle (the longer the delay), the better. – Frank Hileman Jan 13 '17 at 18:37

2 Answers2

2

Retries in NServiceBus are intended to be a method for handling transient issues such as network failures, reboots, etc. in which case the issue is expected to be resolved fairly quickly, and you still expect the message to be handled as soon as possible. If instead you have an exception because of a command that is invalid for business reasons, you probably want to catch the exception and send a response message/publish an event, indicating that the command could not be carried out because it would violate a business rule.

The general idea is that infrastructure exceptions are handled by the NServiceBus infrastructure, and business exceptions are handled by your business logic - in message handlers, sagas, domain model, etc.

pnschofield
  • 334
  • 2
  • 5
0

The failures that "fail-fast" apply to are the kind that you can detect and report immediately. In an NServiceBus, these manifest as exceptions. When an exception is thrown by a service, NServiceBus can be configured to immediately retry a certain number of times (five, by default). This works if the problem is not a persistent one.

If five retries do not correct the problem, you can safely assume that some dependent service has a problem (i.e. a JSON service on which your service depends is down, or a database deadlock occurred), it is common to back off, wait awhile, and perform a retry. NServiceBus will do this up to five times by default, with an increasing amount of delay each time.

In short, "fail fast" only applies when you can actually fail fast. It doesn't apply in situations where a timeout occurs, or where problems can occur that are outside of your control.

Further Reading
NServiceBus Recovery Options

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • This kind of goes against some high-availability / high scalable applications such as Netflix/Hystrix are doing right now. There's no retry after a timeout, but an understanding that if a timeout occurred, than it's a failure. It may not be a "hard" failure (like a burnt server), but it's still a failure in the sense that something is happening outside the expected behavior (attend the request within 500ms, for example). – Machado Jan 10 '17 at 21:13
  • Alright. But if you get into a timeout situation, haven't you already fast-failed and notified somebody of the problem? The delayed retries are just a mechanism that adds robustness to a fast-fail that has already occurred. – Robert Harvey Jan 10 '17 at 21:17
  • In other words, no, automatic retrying is not fail-fast, but neither are timeouts, and both still have their useful purposes. Conversely, if a company finds no addtional benefit in timeouts or retries, they can choose not to use them. – Robert Harvey Jan 10 '17 at 21:26
  • That's precisely what I'm thinking about, hence the question. What are the benefits of NOT using retries ? I'm leaning towards the fail-fast side of the equation, and obviously the system must be coded to handle this scenario instead of relying on silent retries to correct transient problems. – Machado Jan 11 '17 at 13:05
  • You've already got "fail fast," whether you use retries or not. – Robert Harvey Jan 11 '17 at 13:43