[[I touched on Outgoing Queues last week so thought I would add some more detail. This post has been in my draft folder for a while so may have some duplicate information to last time.]]
MSMQ has a dilemma – what to expose of its inner works and what to hide.
For example, back in MSMQ 1.0 you could use MSMQ Explorer to see the internal queues but not the outgoing queues.
This immediately created two different problems.
- Customers would delete any queue they had not created and did not see a use for.
- Messages stuck in outgoing queues were invisible to everything except Performance Monitor.
As a result, the product group flipped the bits in MSMQ 2.0 and the internal queues became hidden while the outgoing queues were made visible.
Now customers can’t break MSMQ so easily and they have a much better awareness of what’s in the outgoing queues (or what isn’t).
Outgoing queues are there to be poked and prodded so we had better find out what they’re for and what’s possible.
According to the MSMQ Glossary, an Outgoing queue is:
“A temporary internal queue that holds messages for a remote destination queue. The path name and format name of an outgoing queue are identical to the path name and format name of the corresponding destination queue. An outgoing queue is distinguished from its corresponding destination queue by the fact that the outgoing queue is located on the sending computer.”
You only get outgoing queues when you send messages to another machine. If your application is using a local queue then the MSMQ queue manager will simply write the messages straight into it. For local messaging, MSMQ behaves like a synchronous system so why waste time creating an outgoing queue when sender and receiver must be online at the same time? But I digress.
The outgoing queue stores messages just like the existing local private, public and system queues. So resources are consumed to maintain them. Also, you can write applications to manipulate them. Take the Local Admin API, for example:
- Listing of the outgoing queues of a computer. These are the internal queues, created on the fly by MSMQ, to hold messages destined for remote queues. For example, when sending messages to a remote queue machine1\queueA, you would see an internal outgoing queue named “machine1\queueA” on the sending computer.
- Obtaining a variety of internal information about a specific queue, such as how many messages in an outgoing transactional queue are still un-Acked.
- Reading the messages in a specific outgoing queue. For example, when sending messages to a remote queue while the sending computer is offline, it is possible to Peek all messages sent to that remote queue as they accumulate in the corresponding outgoing queue (waiting to be sent) and delete specific messages.
- Stopping/resuming delivery from a specified outgoing queue. This may be helpful in situations where the target computer can’t cope with new messages, or to allow a type of deferred delivery mechanism controlled programmatically.
- Purging all messages in a queue (private, public, or outgoing queue). This is much more efficient than deleting messages one-by-one.
Normally I’d advise against manipulating the outgoing queues directly. This isn’t because it is inherently dangerous – although you can, of course, delete messages you didn’t intend to – but because your application design should be good enough that you don’t need to take a spanner to the system to keep it running. Also, you need to be a local administrator to access the outgoing queues with the local admin API which poses a number of security questions.