Back off strategy - rebus-org/Rebus GitHub Wiki

When Rebus is set up to receive messages, it will use one or more threads to poll the transport for the next message.

If a message is received, it will then be dispatched to the Incoming messages pipeline, which is where messages go to finally end up in one of your message handlers.

If NO message is received, the current back-off strategy will have a Wait()-call made on it. The back-off strategy then decides for how long it wants to block the thread. This is done to avoid excessive CPU usage and overloading the transport with unnecessary polling during idle periods.

The default back-off strategy is a compromise, as it balances the above consideration with preserving a fairly low latency – therefore it will poll the transport fairly quickly during the first second of running idle (100 ms), and after that it will resort to waiting 250 ms between receive attempts for the rest of the time.

If you can tolerate higher latencies (or if you have many threads and/or high parallelism), you might want to relax them a bit by customizing the back-off times – it can be done like so:

Configure.With(...)
	.(...)
	.Options(o => {
		o.SetBackoffTimes(
			TimeSpan.FromMilliseconds(100),
			TimeSpan.FromMilliseconds(200),
			TimeSpan.FromSeconds(1)
		);
	})
    .Start();

and you can even replace the back-off strategy completely by registering your own IBackoffStrategy like so:

Configure.With(...)
	.(...)
	.Options(o => {
		o.Register<IBackoffStrategy>(c => {
			var strategy = new MyOwnBackoffStrategy();
			return strategy;
		});
	})
	.Start();

where you would probably wrap the registration part in an extension method that makes it read better – e.g. like this:

Configure.With(...)
	.(...)
	.Options(o => o.UseMyOwnBackoffStrategy())
	.Start();