SQL Server Native Delayed Delivery

The SQL Server transport can take advantage of native delayed delivery without the need to run the timeout manager. Instead, the transport creates dedicated infrastructure which delays messages using native SQL Server transport features.

When a message delay time lapses, SQL Server transport moves a batch of messages to the destination queue. Note that this means the exact time of delivering a delayed message is always an approximation.

The native delayed delivery feature of the SQL Server transport is not available to send-only endpoints.

Configuration

The settings described in this section have default values as shown in the snippets. The settings can be fine-tuned to fit a particular system's needs, e.g. messages are checked for expiration more frequently resulting in more accurate delivery times.

Native delayed delivery mechanism has been introduced in version 3 of the transport. Older endpoints that use Timeout Manager can be migrated to the new mechanism by following the upgrade guide.

Table suffix

Delayed messages are stored in a dedicated table named endpoint-name.suffix. The suffix is set to Delayed by default, but can be overwritten using:

delayedDeliverySettings.TableSuffix("Delayed");

Polling interval

Messages are checked for expiration every second. The polling interval can be configured using:

delayedDeliverySettings.ProcessingInterval(TimeSpan.FromSeconds(5));

Polling batch size

On each query, a batch of messages is picked and dispatched. The maximal size of the batch can be specified with:

delayedDeliverySettings.BatchSize(100);

Backwards compatibility

When upgrading to a version of the transport that supports native delayed delivery, it is safe to run a set of endpoints that include both endpoints using native delayed delivery as well as the timeout manager:

  • Endpoints with native delayed delivery can send delayed messages to endpoints using the timeout manager.
  • Endpoints with native delayed delivery can continue to receive delayed messages from endpoints using timeout manager.

Disabling the timeout manager

To assist with the upgrade process, the timeout manager is still enabled by default. Any delayed messages stored in the endpoint's persistence database before the upgrade will be sent when their timeouts expire. Any delayed messages sent after the upgrade will be sent through the native delayed delivery infrastructure, even though the timeout manager is enabled.

Once an endpoint has no more delayed messages in its persistence database, there is no more need for the timeout manager. It can be disabled by calling:

delayedDeliverySettings.DisableTimeoutManagerCompatibility();

At this point, all the .Timeouts and .TimeoutsDispatcher tables for the endpoint can be deleted from the database. In addition, the endpoint no longer requires timeout persistence, so those storage entities can be removed from the persistence database as well.

Timeout Manager should be also disabled for newly created endpoints, i.e. the endpoints that use the native delayed delivery implementation and haven't been deployed yet.

Last modified