WS08 Feature of the Week #14 - Sub-queues in MSMQ 4.0
What are sub-queues? Subqueues are implicitly created local queues that are logical partitions of a physical queue. Applications can use subqueues to group messages. Subqueues are implicitly created when opened, are deleted when empty, and have no open handles. Messages cannot be sent to a subqueue. Messages can be received from subqueues, moved between the main queue and its subqueue, or moved between a pair of sibling subqueues.
Subqueues do not have their own properties or state, but share the properties and state of their parent queue. For example, a subqueue does not have its own quota, access control list (ACL), or transactional type. Subqueues share the quota of the main queues. Messages in the subqueues consume the quota of the main queue. Subqueues cannot be created under journal and other system queues, or other subqueues. If journaling is enabled, copies of messages that are removed from a subqueue are sent to the journal queue of the main queue.
So why sub-queues? MSMQ-based applications often require messages to be grouped based on some criteria. Previously, the only way to do this was to create several queues and when a message arrived in the main queue, move the message into a specific queue based on some selection criteria.
Here’s the thing: moving messages between physical queues is a resource-intensive process. If you are wanting to build a high performance application, it is best to try to avoid this resource-intensive process. But if you were building an application based on MSMQ 3.0, this was not very feasible. Now, the new sub-queues feature enables you to logically group messages within a single queue without the need of creating another physical queue.