NServiceBus for dummies who want to be smarties 2… second post, this time on how to do some more stuff with NServiceBus.
How to do stuff when the service starts
Make a class implement IWantToRunAtStartup, e.g. like so:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
public class BuildPoolOfExpensiveObjects : IWantToRunAtStartup { public void Run() { // build that pool } public void Stop() { // dispose it properly } } |
How to speed up delivery of messages that are transient in nature
If your message contents get stale after a short period of time, it makes no sense to use reliable messaging where messages are written to disk before the message queueing service attempts to deliver the messages to their destination. Therefore, to be true to the transient nature of the messages and speed up delivery, you can decorate some of your messages with the [Express] attribute. E.g. like so:
|
1 2 3 4 5 |
[Express] public class SomeFrequentlyChangingValueJustChanged : IMessage { public double Value { get; set; } } |
How to make messages expire after some amount of time
If you know your message content does not make sense after some period of time, say one hour, just decorate your message with the [TimeToBeReceived] attribute – e.g. like so:
|
1 2 3 4 5 |
[TimeToBeReceived]("01:00:00")] public class AnotherPeriodicallyChangingValueJustChanged : IMessage { public double Value { get; set; } } |
Note that the argument to the attribute must be Parseable – unfortunately C# does not allow for calling e.g. TimeSpan.FromHours(1) in the attribute initializer.
How to stop logging all kinds of noise to the console
Logging is good, but not all the time. To disable all of NServiceBus’ logging, just make your endpoint config implement the interface IWantCustomLogging and do nothing in the Init method – e.g. like so:
|
1 2 3 4 5 6 7 |
public class EndpointConfig : IConfigureThisEndpoint, AsA_Server, IWantCustomLogging { public void Init() { // ... do nothing here =) } } |
Conclusion
That concludes today’s “NServiceBus for dummies who want to be smarties”. This was about how to add some more life to your service. Next post will be about the question: where do the messages go?
I’m really enjoying this series so far. Next up (please): how to get NServiceBus to use a database to store messages. I’m conceptually missing that whole part – when it’s required, when it’s not, what it means to MSMQ when a DB is involved. But quite aside from that, keep these focused posts coming, and thank you.
I don’t think I can see why you would want to store messages in a DB? Messages are a means of communication between parts of your application, and as such are not really candidates for being treated as entities.
Dru Sellers did a series of posts called “Why messaging”, you should really check them out – intro is here, and a really good description of what constitutes a message is here.
You can find all his Codebetter-posts here.