MSMQ
If you’ve never looked into MSMQ, you should take a few minutes and have a look. Not necessarily because it’s something you’ll use today, but because it’s cool technology that you probably will have a use for sometime, and if you don’t know about it, you’ll probably reinvent this particular wheel..
MSMQ is a message queueing technology. It’s been around since Windows 2000, part of the OS, and in my experience anyway, it’s not used all that often. With the .NET framework, it’s really easy to use.
A Queue is a named place where messages go until someone is ready to pick them up. Here’s some code:
MailItem item = new MailItem();
item.To = “somewhere@somewhere.com”;
item.Subject = “Hello”;
item.Body = “This is an email message.”;
MessageQueue myQueue = new MessageQueue(“.\\Outgoing Email”);
myQueue.Send(myNewEmailObject);
MailItem is an object I’ve defined somewhere. It supports serialization. What this code does is create this object, initializes it, and puts it on the “Outgoing Email” queue. Presumably someone, somewhere, is listening on this queue, and will retrieve my MailItem and actually send an email.
Why not just send the email immediately? We might need to send an email in the middle of some other operation.. we might need to send an email at a time when we can’t stop what we’re doing and block in an attempt to connect to the mail server. By putting the item onto the Outgoing Email queue, we’re letting someone else deal with actually getting the message sent, whose job it is to do that, so they’re probably better at it (dealing with retries, logging errors in a standard way, whatever).
Some benefits of using the queue and a separate sender process:
- Location Independence. MSMQ supports public queues, which are registered in the Active Directory. This means you could have one corporate “Outgoing Email” queue, and any application in the company could post messages onto it. It doesn’t matter what machine that queue lives on, or what machine the process which is actually sending the emails is running on.
Scalability. More than one process can be listening on a queue, and a message will be given to the first one that asks for it (only). So if your bottleneck is CPU on one system (which it wouldn’t be in the email example, but humour me), drop down another box and run another instance of the mail sender. Now they’ll share the load.
Resilience. Queue data persists, so if the power goes out, when it comes back on presumably you’ll be able to pick up where you left off. Also, if the application that’s sending the messages breaks, messages will queue up until it comes back online. (Compare this with using something like .NET Remoting where, if the server is gone, you’re out of luck).
One Usenet posting mentions getting 16k messages a second posted to a queue.. Not bad.