Source Journaling

 

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

Source journaling allows you to track the messages sent by a computer. It can be used to track messages that were delivered successfully to the next computer along its route, messages that could not be delivered, or both.

Tracking Messages

To track messages that were successfully sent by the local computer, set the journaling level of the message (PROPID_M_JOURNAL or MSMQMessage.Journal) to MQMSG_JOURNAL. Then when you send the message to remote destination queues, a copy of the message is placed in the source computer's journal if the message is delivered successfully to the next computer. This type of journaling is called positive source journaling.

Note

This does not mean the message has successfully reached its destination queues, only that the local computer was able to deliver the message to the next computer along its route.

However, when you send messages to local destination queues the message can be placed in one of two journal queues:

• If the local destination queue has not enabled target journaling (this is the default behavior), a copy of the message is saved to the computer journal only after the message has been removed from the local destination queue.

• If the local destination queue has enabled target journaling, a copy of the message is saved to the queue's journal after the message has been removed from the queue. The message is not, in this case, stored in the computer journal. Message Queuing never stores more than one copy of a message on a single computer at one time.

Tracking Messsages Not Delivered

To track messages that were not delivered, set the journaling level of the message to MQMSG_DEADLETTER. This type of journaling is called negative source journaling. When you specify this type of source journaling, Message Queuing reacts differently depending on the type of message you send.

For nontransactional messages, the message is placed in the dead-letter queue of any computer that cannot deliver the message to the next computer. This can be the source computer, or any routing server used to pass the message on to its destination.

For transactional messages, a copy of the message is placed in the transactional dead-letter queue of the source computer only if the source queue manager receives a negative acknowledgment message or does not receive a confirmation from the target queue manager indicating that the message was retrieved from its destination queue (for example, if the message's time-to-be-received timer elapses before the source queue manager receives an acknowledgment message indicating that the message reached the destination queue or was retrieved from it). No notification is returned within the transaction confirmation process if the message is not delivered, is not received, or the receiving transaction is aborted. Messages found in the transactional dead-letter queue may be used as a guaranteed negative acknowledgment.

For transactional messages, MSMQ 1.0 acts differently than the later versions of Message Queuing.

MSMQ 1.0 only allows you to choose if you want to save copies of messages sent successfully. MSMQ 1.0 always sends an unconfirmed transactional message to the transactional dead-letter queue, regardless of whether MQMSG_DEADLETTER is or is not specified.

MSMQ 2.0 and later versions allow complete control over source journaling. (If you are running MSMQ 1.0 applications on an MSMQ 2.0 computer, you can force the computer to use the MSMQ 1.0 semantics by setting the XactDeadLetterAlways registry entry to 1.)

When a message is placed in a dead-letter queue, Message Queuing changes the class property of the message (PROPID_M_CLASS or MSMQMessage.MsgClass) to reflect the last known status of the message. For example, Message Queuing will change the class of the message and place it in the appropriate dead-letter queue if the message's time-to-reach-queue timer or time-to-be-received timer expires.

When you store messages in a journal or dead-letter queue, clear these queues periodically to remove messages that are no longer needed. Messages stored in journal and dead-letter queues count against the quota for the computer where the queues reside (the computer quota is set by the administrator).

Target Journaling

For information on	See
Target journaling	Target Journaling
The queues used for journaling	Journal Queues
The dead-letter queues	Dead-Letter Queues
Positive and negative acknowledgment messages	Acknowledgment Message Classes

Reading and Requesting

For an example of	See
Requesting positive source journaling	C/C++ Code Example: Requesting Source Journaling  Visual Basic Code Example: Requesting Source Journaling
Reading messages in the computer journal	C/C++ Code Example: Reading Messages in the Computer Journal  Visual Basic Code Example: Reading Messages in the Computer Journal
Requesting negative source journaling	C/C++ Code Example: Requesting Source Journaling  Visual Basic Code Example: Requesting Source Journaling
Reading messages in dead-letter queues	From DEADLETTER queue  C/C++ Code Example: Reading Messages in the Dead-Letter Queue  Visual Basic Code Example: Reading Messages in the Dead-Letter Queue  From DEADXACT queue  C/C++ Code Example: Reading Messages in the Transactional Dead-Letter Queue  Visual Basic Code Example: Reading Messages in the Transactional Dead-Letter Queue