- Getting started
- Different bus modes
- How does rebus compare to other .net service buses?
- 3rd party extensions
- Rebus versions
- 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
- Timeout manager
- Delivery guarantees
- Unit of work
- Workers and parallelism
- Wire level format of messages
- Handler pipeline
- Polymorphic message dispatch
- Persistence ignorance
- Saga parallelism
- Transport message forwarding
Transports (not a full list)
- Auto flowing user context extensibility example
- Back off strategy
- Message compression and encryption
- Fail fast on certain exception types
- Log message pipelines
- Incoming messages pipeline
- Incoming step context
- Outgoing messages pipeline
- Outgoing step context
Prominent application services
Clone this wiki locally
Similarly to how Pub-sub-messaging requires more or less configuration depending on the choice of transport, the same thing holds for timeouts.
"Timeouts", or "deferred messages" as we also call it, is when you
await bus.Defer(TimeSpan.FromMinutes(2), new WakeMeUp()) in order to have the
WakeMeUp message delivered to yourself in 2 minutes.
Generally, the transports can be divided into two camps:
- those that DO support deferred messages, and
- those that DO NOT support deferred messages
where it requires less configuration to work with transports that have native timeouts.
When the transport does not support delaying messages natively, it is necessary to configure a "timeout manager" with Rebus.
Transports WITH native support for deferred messages
When the transport supports delayed delivery, the message is usually deferred simply by setting a timestamp on the message when sending it, causing it to stay invisible in its destination queue until that time comes.
This works out-of-the-box with the Azure Service Bus tranport, the Azure Storage Queues transport, and the Amazon SQS transport. Curiously, it also works with the SQL Server transport, as all messages are provided with a
DateTime2 value, which is used by the transport when querying for messages to receive.
Transports WITHOUT native support for deferred messages
When the transport is not capable of delaying delivery of messages natively, Rebus needs some kind of timeout manager installed.
Each Rebus endpoint can be its own timeout manager by configuring a timeout storage like so:
Configure.With(...) .(...) .Timeouts(t => t.StoreInSqlServer(..)) .(...)
which causes deferred messages to be stored in a table in SQL Server. Alternatively, another Rebus endpoint can be used as the timeout manager - that can be configured by going
Configure.With(...) .(...) .Timeouts(t => t.UseExternalTimeout("timeouts")) .(...)
which will cause deferred messages to be sent to the
timeouts queue. This way, you can configure one or more central timeout managers which handle timeouts for several endpoints, thus relieving them of the burden of having to have a timeout storage configured.
We do our best to ensure that the documentation wiki is up-to-date - please let us know if you think there's something we should do better.