Condividi tramite

Transactional MSMQ on a cluster

  • Articolo

Before Windows 2008 (MSMQ 4.0) there was only one option if you needed to read messages transactionally on a high availability cluster - the application had to be clustered in the same resource group as the MSMQ service hosting the queues. This was because only local receive operations could be transactional on Windows 2003 (MSMQ 3.0).

Now remote receives can be transactional so the application can be run elsewhere, such as on the local nodes, which makes development / testing / administration that much easier.

There is a caveat to this - you will experience a performance difference between local and remote receive operations which makes the decision where to locate applications less clear cut. There are two reasons for this:

  1. Receive operations use RPC. If the application and MSMQ resource are working together, local RPC (LRPC) function calls are made. If the application is remote then the transport protocol has to be used at both ends, adding a large overhead.
  2. For sending messages transactionally over the wire, MSMQ employs its own lightweight mechanism that uses acknowledgement messages. Receiving messages remotely, though, requires DTC for the transactional support which is a much more heavyweight method.

References

[[Thanks to Joseph Donahue for typo checking]]

Comments

  • Anonymous
    February 05, 2010
    The comment has been removed
  • Anonymous
    February 07, 2010
    Hi Denny, Just pasting the solution from Serverfault.com for anyone interested: "It turns out that the cause of the slow MSMQ reading was actually an application problem. The services which read from the queue then go to stuff on a file share. The file share started taking longer and longer, which caused the services to run slower, which caused the queues to back up, and now we have a mess. Apparently our user base has grown much faster than planned and we are maxing out one of the RAID groups on the SAN which hosts the file shares. Monday we'll be putting in a rush order for more SAN space with our vendor." Cheers John Breakwell (MSFT)