Processing Trigger Messages

Applies To: Windows Server 2008

Processing trigger messages

The Message Queuing Triggers service starts to process the messages in the queue as soon as the service starts running. The service starts at the beginning of the queue and processes all the messages in the queue. After processing all the existing messages, the service waits at the end of the queue for a new message. If the service is stopped and restarted, it will process all messages remaining in the queue again.

Processing messages having the same priority

When all the messages sent to a monitored queue have the same priority, new messages are always placed at the end of the queue. After processing all the existing messages in the queue, the Message Queuing Triggers service will activate the trigger each time a new message arrives at the end of the queue. The illustration below shows a queue with four messages and portrays a trigger with the peeking type of message processing. The Message Queuing Triggers service already peeked at message 1, message 2, message 3, and message 4 and will continue to peek at messages as they arrive at the end of the queue.

Processing messages having different priorities

When messages with different priorities arrive in a queue, a new message can be placed anywhere in the queue. For example, when a high-priority message is placed somewhere in the queue, the Message Queuing Triggers service processes the new message next regardless of where it is placed in the queue and then continues to process all the low-priority messages that are in the queue.

In the next illustration, which also portrays a trigger with the peeking type of message processing, the Message Queuing Triggers service makes one pass through the queue peeking at message 1, message 2, message 3, and message 4. Then, when message 5, a new message of priority 1, arrives at the queue, it is placed between message 2 and message 3. The service goes back and peeks at message 5 and then continues to peek at message 3 and message 4 again.

Note that in this case, the trigger is activated twice for message 3 and twice for message 4. You can avoid messages being read more than once by using a transactional queue (where all messages have a priority of 0). For more information about transactional queues, see Transactional Messaging.

Processing messages within transactions

When a message is retrieved from within a transaction, Message Queuing does not roll back the cursor if the transaction is aborted. For example, given a queue with two messages, message 1 and message 2, if you remove message 1 from within a transaction, Message Queuing will move the cursor to message 2. However, if the transaction is aborted for any reason, message 1 is inserted back into the queue, but the cursor remains at message 2.

For the peeking type of message processing in a queue containing one message when a COM component invoked by a trigger rule receives the message invoking it and the same COM component is configured to be part of an external transaction, if any operation in the transaction cannot be completed, the transaction is aborted and the message is returned to the queue. Then, if the trigger is serialized, the Triggers service waits until the process performed by the COM component ends (aborts) before starting to process a message again. In this case, the queue cursor moves on to wait for the next message, and the trigger does not invoke the COM component again for the same message. However, if the trigger is not serialized, as soon as the Triggers service finishes peeking at the message, it sends a request to peek at the next message and waits for a message to appear in the queue. Therefore, when the transactional COM component is invoked, there is already a pending peeking operation in the system. When the message is returned to the empty queue in the aborted transaction, it arrives at the queue in the position to which the queue cursor is pointing. In this case, the returned message is processed again, the COM component is invoked for the same message, and a perpetual loop exists until a new message arrives or all the operations in the transaction can be completed.

Sample implementation of Message Queuing Triggers

Suppose you create a new trigger named PrivateTrigger, which is associated with the private queue MyComputer\MyQueue and has two rules attached to it: MyRule1 and MyRule2.

Each of these rules defines a condition (such as "Message label contains marketing") and an action to be taken when the condition is true (such as "open MSPaint.exe" with the parameter Message label).

When a message arrives at MyComputer\MyQueue, the Message Queuing Triggers service is notified. Next, for the trigger, PrivateTrigger, defined for that queue, the rules MyRule1 and MyRule2, which are attached to that trigger, are applied. Last, Microsoft Paint is opened if all the conditions for those rules are satisfied (are true).

For more information about implementing the Message Queuing Triggers service, see Installing Message Queuing Triggers.