ID: Q182121
The information in this article applies to:
After a restart of the Microsoft Message Queue Server (MSMQ) Queue Manager on a computer with a connector service, any of the following may occur:
The first problem described above occurs when the messages are not in the connector queue after Queue Manager initialization. The messages are returned to the temporary queue and moved back to the connector queue. The recovery process may take a significant amount of time to determine the connector queue and place the messages there, so that they can be read by the application.
The second problem described above occurs if, after recovery, the message cannot be read from the connector queue. The message can be seen in the performance counter, but when the application tries to read it, it stops responding. This is because Transactional messages are stored in two steps. The first step is to store the message on the disk and update the logger. The second step allows the application to read the message. There is a problem in the logic of the first step that prevents the second step from happening.
In the third case described above, you should understand that, during recovery, the messages are ordered according to the packet allocation time. For the connector, it is possible for packets to be out of order chronologically.
To work around these problems, obtain the hotfix mentioned in the STATUS section of this article. With the hotfix installed, MSMQ returns the message directly to the connector queue during recovery. To properly track this, a field was added to the end of the packet containing the GUID of the destination connector queue.
If the Foreign Connection Network (CN) is deleted (the connector queue is no longer valid), MSMQ identifies this case during the validation process. In such a case, MSMQ closes the queue and deletes all the messages. However, MSMQ does not send any negative acknowledgment (nack), because the connector queue is marked as a temporary queue in the driver. The sender will receive Time To Reach Queue expiration nack.
Microsoft has confirmed this to be a problem in Microsoft Message Queue Server version 1.0. A supported fix is now available, but has not been fully regression- tested and should be applied only to systems experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft recommends that you wait for the next Service Pack that contains this fix. Contact Microsoft Technical Support for more information.
After obtaining the hotfix from Microsoft Technical Support, perform the following steps to install it:
1. Copy I0267.exe (for computers with an Intel processor) or A0267.exe
(for computers with an Alpha processor) to an empty directory and then
run it. The Readme.txt file contains these instructions, as well as
descriptions of the problems corrected by the hotfix.
Hotfix files
------------
Mqqm.dll
Readme.txt
service.
service. To do this, do either one of the following, depending on
whether your computer is clustered:
- On a computer running Microsoft Cluster Server, use Cluster
Administrator to take the Microsoft Message Queue resource offline.
- On a non-clustered computer, open Control Panel Services and stop the
Microsoft Message Queue service.
you can restore it if there are problems with the hotfix on your
computer.
this procedure) to the %windir%\System32 directory.
following methods (depending on whether your computer is clustered):
- On a computer running Microsoft Cluster Server, use Cluster
Administrator to bring the Microsoft Message Queue resource online.
- On a non-clustered computer, open Control Panel Services and start
the Microsoft Message Queue service.
service (that you had stopped in step 2 of this procedure).
Keywords : kbbug1.00 MQQueue
Version : WINNT:1.0
Platform : winnt
Hardware : ALPHA x86
Issue type : kbbug
Solution Type : kbfixLast Reviewed: March 10, 1998