If you have worked with NServiceBus, and you’ve tried Rebus as well, you might be wondering where that nifty [TimeToBeReceived] attribute went? You know, that attribute that you would decorate your messages with when you wanted to have MSMQ expire the messages for you to prevent your queues from clogging up with irrelevant messages if the recipient was down.
The answer is: There’s no such attribute in Rebus! And that’s because that would require your messages assembly to reference Rebus, and that should not be a requirement. Rebus allows your messages to be POCOs, so your messages assembly should be allowed to stay “plain” in that POCO sense.
How to set time to be received then?
With Rebus you set the time to be received property of your messages by attaching a special Rebus header to your messages: Headers.TimeToBeReceived. The value must be a HH:mm:ss string, e.g. "00:01:30" to set a 1 minute and 30 seconds expiration timeout on a message.
E.g. like so:
|
1 2 3 |
var somethingHappened = new SomethingHappened { Time = DateTime.UtcNow }; bus.AttachHeader(somethingHappened, Headers.TimeToBeReceived, "00:00:30"); bus.Publish(soomethingHappened); |
This header will be detected later on by the transport implementation (e.g. MsmqMessageQueue), which will use the approproate settings when sending the message.
In MSMQ’s case, the message will then be deleted by the queueing system when the timeout expires, which is a nifty feature that can be used to avoid flooding the queueing system with expired and irrelevant messages.
But doesn’t that require a lot of tedious manual work?
Yes – which is why I suggest you use some of the nifty hooks in Rebus to reduce the amount of tedium involved. More on that in the next post.