FIX: MSMQ Transactional Messages Go to Dead-Letter Queue When TTRQ Is Shorter Than TTBR (290892)

SYMPTOMS

When the Time-To-Reach-Queue (TTRQ) and Time-To-Be-Received (TTBR) values are set to different time periods, if the MSMQ service on the client computer is restarted in the interval between TTRQ and TTBR, incorrect results may be recorded depending on the options that are set for the message:

Transactional message are moved to the Xact dead-letter queue without being marked as having reached the queue, even though the message already arrived safely at the destination. On Microsoft Windows NT 4.0, this action will always occur unless the fix provided in this article is applied and the registry changed.
If the client application sets PROPID_M_ACKNOWLEDGE to MQMSG_ACKNOWLEDGMENT_FULL_REACH_QUEUE or MQMSG_ACKNOWLEDGMENT_FULL_RECEIVE, the admin queue designated for the acknowledgement will incorrectly get both a positive acknowldgement (ack) and a negative acknowledgement (nack).
If the client application sets PROPID_M_ACKNOWLEDGE to MQMSG_ACKNOWLEDGMENT_NACK_REACH_QUEUE or MQMSG_ACKNOWLEDGMENT_NACK_RECEIVE, the admin queue designated for the acknowledgement will incorrectly get a nack.

CAUSE

When a transactional message arrives at the target queue, the target computer sends back an internal receipt called an order acknowledgement. If the sending computer does not get the order acknowledgement receipt until the TTRQ expires, it moves the message to the Xact dead-letter queue. After it gets the receipt, it waits for the final acknowledgement which is sent when the message is removed from the target queue. During this period, it saves the message in an outgoing queue. The order acknowledgement is not persisted and is discarded over a restart of the MSMQ service.

During the start of the MSMQ service, it goes through a message recovery phase. In this phase, the message is still in the outgoing queue but there is no indication that it arrived to the destination because the order acknowledgement is gone and the TTRQ timer is expired. This combination causes the MSMQ service to move the message to the Xact dead-letter queue with a class of "Time to Reach Queue Expired".

If PROPID_M_ACKNOWLEDGE is set to MQMSG_ACKNOWLEDGMENT_FULL_REACH_QUEUE, MQMSG_ACKNOWLEDGMENT_FULL_RECEIVE, MQMSG_ACKNOWLEDGMENT_NACK_RECEIVE, or MQMSG_ACKNOWLEDGMENT_NACK_REACH_QUEUE, the MSMQ service also generates a nack to the admin queue specified in the properties of that message. This nack may come from either the sending computer's MSMQ service based on the TTRQ timer or the target computer's MSMQ service.

The PROPID_M_SRC_MACHINE_ID of the message should be checked against the sending computer's GUID to determine where the nack was generated. If it was generated locally, the nack may not be valid, and the message disposition should be treated as "in doubt". This may require that a reconciling process be built into the application to determine whether the message was processed from the target queue to avoid duplicate updates should the application decide to resend the message.

A nack whose PROPID_M_SRC_MACHINE_ID is from the target computer should be treated as valid. In this instance, the target computer has discarded the message and sent this nack without the message being received. In order for that application to have that message data processed, it will need to extract the body of the message from the nack and send a new message with the data.

RESOLUTION

A supported hotfix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Only apply it to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next Windows NT Server 4.0 service pack that contains this hotfix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=support

NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

The English version of this fix should have the following file attributes or later:

    Date          Time     Version   Size    File name       Platform
    ------------------------------------------------------------------
    20-FEB-2001   10:11               11k    Crdbsp7.sql     x86
    20-FEB-2001   10:11               20k    Mq2ndnd.exe     x86
    20-FEB-2001    9:44    321        61k    Mqac.sys        x86
    20-FEB-2001    9:44    321        34k    Mqcertui.dll    x86
    20-FEB-2001    9:44    321        34k    Mqdbmgr.dll     x86
    20-FEB-2001    9:44    321        58k    Mqdscli.dll     x86
    20-FEB-2001    9:44    321        56k    Mqdssrv.dll     x86
    20-FEB-2001    9:44    321       222k    Mqis.dll        x86
    20-FEB-2001    9:44    321        16k    Mqkeyhlp.dll    x86
    20-FEB-2001    9:44    321       139k    Mqoa.dll        x86
    20-FEB-2001    9:44    321         9k    Mqperf.dll      x86
    20-FEB-2001    9:44    321       494k    Mqqm.dll        x86
    20-FEB-2001    9:44    321       108k    Mqrt.dll        x86
    20-FEB-2001   10:06    321     1,789k    Mqsetup.dll     x86
    20-FEB-2001    9:44    321        14k    Mqsvc.exe       x86
    20-FEB-2001    9:44    321       105k    Mqutil.dll      x86
    20-FEB-2001    9:44    321        61k    Msmq.cpl        x86

This fix is available to change the disposition of transactional messages on Windows NT 4.0. This change carries application design considerations when using transactional messages. Using this fix and incorporating these design changes allows for application behavior for transactional messages that is consistent across Windows NT 4.0 and Microsoft Windows 2000 platforms.

To eliminate the problem of messages being sent to the Xact dead-letter queue incorrectly (due to TTRQ timeouts being incorrectly handled on MSMQ service restart) requires adding a registry key to enable the Xact dead-letter behavior that is used in MSMQ 2.0. To do this, add the following registry key and set it to a value of "0":

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\XactDeadLetterAlways

The application designer must now incorporate the use of acks and nacks along with an admin queue to send those acknowledgements. The following items address the three situations described in the "Symptoms" section of this article:

Problem: Transactional message are moved to the Xact dead-letter queue without being marked as having reached the queue, even though the message already arrived safely at the destination.

Resolution: Use of the XactDeadLetterAlways registry value will eliminate this problem unless the application has coded PROPID_M_JOURNAL to MSMQ_DEADLETTER in order to get messages sent to the Xact dead-letter queue.
Problem: If the client application sets PROPID_M_ACKNOWLEDGE to MQMSG_ACKNOWLEDGMENT_FULL_REACH_QUEUE or MQMSG_ACKNOWLEDGMENT_FULL_RECEIVE, the admin queue designated for the acknowledgement will incorrectly get both an ack and a nack.

Resolution: In the case where both an ack and a nack are found for a message, the nack may be discarded if PROPID_M_SRC_MACHINE_ID is identified as the local computer. There should not be both an ack and a nack for the same message where PROPID_M_SRC_MACHINE_ID is the target computer. A nack that is generated locally by a timer, and the existence of an ack from the target computer overrides the incorrect local generation of the nack.
Problem: If the client application sets PROPID_M_ACKNOWLEDGE to MQMSG_ACKNOWLEDGMENT_NACK_REACH_QUEUE or MQMSG_ACKNOWLEDGMENT_NACK_RECEIVE, the admin queue designated for the acknowledgement will incorrectly get a nack under the scenario described in the "Symptoms" section.

Resolution: The use of only a nack may require that some reconciliation process be done to validate that the message was not delivered and processed at the target computer and that the nack was incorrectly generated.

MORE INFORMATION

Under MSMQ 1.0, applications put transactional messages which are undeliverable or not received from the target queue within a certain time frame in the Xact dead-letter queue on the sending computer. These applications should have been designed to reconcile messages from the Xact dead-letter queue.

For MSMQ 2.0, the default behavior was changed to not put transactional messages into the Xact dead-letter queue, even though the same timings on delivery may have been exceeded. For MSMQ 2.0, there is a registry key that forces it to behave just like MSMQ 1.0. To implement this, add the following registry key and set it to a value of "1":