In the previous post, we took a look at how Rebus can use the external timeout service to store timeouts its. The other way of using Rebus’ timeout service, is to use the internal timeout service – that’s right, every Rebus service can function as its own timeout manager.
In fact, the external timeout service is just an ordinary Rebus service that throws exceptions if you send it something that is not a TimeoutRequest.
Since the external timeout service is the default choice, you have to do something in order to enable the internal timeout service. Not much, though – check this out:
Configure it
|
1 2 3 4 5 6 |
Configure.With(yourFavoriteContainerAdapter) .(...) //< the usual stuff .Timeouts(t => t.StoreInSqlServer(connectionString, "timeouts") .EnsureTableIsCreated()) .CreateBus() .Start(); |
and like that, your Rebus service will store its timeouts in a table called “timeouts” in the database specified by the given connection string, and it will automatically create the table if it does not exist when it starts up.
Only thing left is to lean back and bus.Defer(tillMañana, yourWorkMan).
Maybe this could be simplified by just moving the TimeoutService to core Rebus – not the console app of course, just the class TimeoutService. Then it would be possible to create my own windows service using e.g. RavenDb as timeout store. Would that be to much bloat? — Reply to this email directly or view it on GitHub.
Great idea! – and that is in fact how it is made 🙂
The TimeoutService class is actually in core Rebus, and you can supply whichever timeout storage you want by doing this:
where myFavoriteTimeoutStorage is something that implements IStoreTimeouts