Freigeben über

Determining Whether a Remote Queue Exists, Part 2A

  • Artikel

Timeouts, acknowledgements, and deadlettering, working together, will help you deal with not just the situation where a remote queue doesn't exist, but all the other things which could go wrong along a message's way from sender to destination.

MSMQ has two timeouts, which can be set individually for each message: "time to reach queue" (TTRQ) and "time to be received" (TTBR). TTRQ controls how long a message can be in transit before arriving in the destination queue. TTBR controls how long a message can sit in the destination queue before it is "discarded". Both timers start as soon as the message is sent, so TTBR actually includes the transit time as well. TTBR also has priority: the message is "discarded" when the TTBR timer runs out, regardless of how much time may be left in TTRQ. (The act of "discarding" a message may include sending a negative acknowledgment (NACK) and/or deadlettering the message, which I'll talk about later.)

When would you set these timers? Well, suppose you wanted to send a stock price update every minute to an app which would display the current price. If there is a transmission problem, updates could build up on the sender. However, since the receiving app only cares about the latest price, all those intermediate updates building up on the sender are meaningless. Any message which hasn't reached the destination queue in one minute is about to be followed by a message bearing more recent information, so it can be safely thrown away. In this case, you would set TTRQ to 60 seconds. Now, once the message arrives in the destination queue, you don't know exactly when it may be received. If the application only checks the queue once per minute, the message could sit in the queue for another 59 seconds before it is actually received. If it sits in the queue for more than 59 seconds, then there should be another message arriving with more recent information, so you could set TTBR to 119 seconds (or maybe 125 just to allow a little extra margin). On the other hand, if there is a transmission problem, setting TTBR like that could leave the app in a situation where it has no information at all — perhaps you'd like to display an old price rather than nothing. Setting TTBR to 1800 (half an hour), for example, would let updates stay in the queue for a while, but if the receiving app is down, having a TTBR set means you will never have more than a known number of updates sitting in the queue, instead of having them build up indefinitely.

What do timeouts have to do with detecting errors? Timeout settings which are appropriate for your business requirements mean that each message has a definite lifetime, at the end of which you will either get an error indication or you will know that the message has been received, if you have applied the right acknowledgement and/or deadletter settings to the message. Knowing that you will always get a definite answer makes writing your application much easier.

Acknowledgements and deadlettering are how your application gets that answer, and I'll talk about them in part 2B.

Message timers documentation: https://msdn2.microsoft.com/en-us/library/ms705726.aspx

Comments