For an overview of Source Journaling for those new to developing reliable messaging applications, read this short TechNet article:
Basically, source journaling keeps a copy of sent messages in a queue on the sending machine.
Positive source journaling puts a copy in the “System Queues\Journal messages” queue when a message has been successfully sent. Note ‘sent’ is not that same as ‘delivered’. MSMQ is an asynchronous, routable protocol so delivery to a remote queue is not guaranteed just because the message has left the originating machine.
Negative source journaling puts a copy in the “System Queues\Dead-letter messages” or “System Queues\Transactional dead-letter messages” (as appropriate) when delivery has failed.
The TechNet article says that enabling both “is the recommended setting” so that success puts a message in the journal queue and failure in the dead-letter queue. Sounds simple enough but what happens in practice? If you enable both on the message but delivery fails, do you get two copies – one because the original sending was successful and another when failure is confirmed? If in doubt, give it a go.
The following are basic scenarios – transactional messages sent between a couple of Windows XP workstations.
Test #1 – positive source journaling only
The results are as expected – as soon as the destination sends back an acknowledgement of successful delivery, a copy appears in the Journal messages queue. Specify a queue without write access instead and you don’t get a journal copy.
Test #2 – negative source journaling only
With the restricted access destination queue, a message immediately appeared in the Transactional dead-letter message queue with a class of “Access is denied”. Again, as expected.
Test #3 – positive and negative source journaling
Here is gets interesting. The message gets delivered to the destination queue but nothing in the journal queue on the sender, which seems contrary to the TechNet article’s description of positive source journaling. In fact you have to wait until the message is received from the destination queue before the copy appears on the sender.
What you are seeing is because there can be only one copy of the transactional message on the sender at any one time.
The message starts out in the outgoing queue. When it is sent, the message still exists in the outgoing queue but is hidden and will stay there until the sender receives acknowledgments (either positive or negative) from the destination. If you just have positive source journaling then the message is moved to the system journal queue when the destination acknowledges delivery. If you have negative source journaling then the message is moved to the XDLQ when either a negative acknowledgement is received or one of the two timers, Time To Reach Queue (TTRQ) and Time To Be received (TTBR), expires.
Therefore if you combine the two types of journaling, you can’t get both results – a copy in the Journal messages queue (when sent) AND in the XDLQ (when not received, for example) – as there is only one copy of the message available. Effectively the positive source journaling is blocked by the negative source journaling until the message is received from the destination queue.
I’ll see if I can get the TechNet article updated to cover this in more detail.