-
-
Notifications
You must be signed in to change notification settings - Fork 362
Back off strategy
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();
Basic stuff
- Home
- Introduction
- Getting started
- Different bus modes
- How does rebus compare to other .net service buses?
- 3rd party extensions
- Rebus versions
Configuration
Scenarios
Areas
- Logging
- Routing
- Serialization
- Pub sub messaging
- Process managers
- Message context
- Data bus
- Correlation ids
- Container adapters
- Automatic retries and error handling
- Message dispatch
- Thread safety and instance policies
- Timeouts
- Timeout manager
- Transactions
- Delivery guarantees
- Idempotence
- Unit of work
- Workers and parallelism
- Wire level format of messages
- Handler pipeline
- Polymorphic message dispatch
- Persistence ignorance
- Saga parallelism
- Transport message forwarding
- Testing
- Outbox
- Startup/shutdown
Transports (not a full list)
Customization
- Extensibility
- Auto flowing user context extensibility example
- Back off strategy
- Message compression and encryption
- Fail fast on certain exception types
Pipelines
- Log message pipelines
- Incoming messages pipeline
- Incoming step context
- Outgoing messages pipeline
- Outgoing step context
Prominent application services