Timeouts

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:

1. those that DO support deferred messages, and
2. 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 visible 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.