1

I would like to ask about Rebus Timeout Manager. I know we have Internal timeout manager and External timeout manager and I have been using Internal timeout manager for quite some time. And I have been sharing one timeout database (Sql Server) for all my endpoints. I would like to know if this is correct. Secondly I would like to know if I can also use one external Timeout Manager for all my endpoints. My questions comes from the the fact that the information contained in the Timeouts table (id,due_time,headers,body) has no connection with the endpoint that sent a message to the timeout manager.

I just would like to get assurance. Regards

Amour Rashid
  • 290
  • 3
  • 11

1 Answers1

0

You can definitely use the internal timeout manager like you're currently doing.

The MSSSQL-based timeout storage is safe to use concurrently from multiple instances, as it used some finely trimmed lock hints when reading due messages, thus preventing issues that could otherwise have happened due to concurrent access.

But it's also a valid (and often very sensible) approach to create a dedicated timeout manager and then configure all other Rebus instances to use that.

And you are absolutely right that the sender of the timeout is irrelevant. The recipient is determined when sending the timeout, so that

await bus.DeferLocal(TimeSpan.FromMinutes(2), "HELLO FROM THE PAST ");

will send the string to the bus' own input queue, and

await bus.Defer(TimeSpan.FromMinutes(2), "HELLO FROM THE PAST ");

will send the string to the queue mapped as the owner of string:

.Routing(r => r.TypeBased().Map<string>("string-owner"))

In both cases, the message will actually be sent to the timeout manager, which will read the rbs2-deferred-until and rbs2-defer-recipient headers and keep the message until it is due.

mookid8000
  • 18,258
  • 2
  • 39
  • 63