JMS provides mechanisms for guaranteed delivery of messages between clients, utilizing the mechanisms we have discussed in this chapter. However, there are cases where guaranteed delivery, acknowledgments, and transactional semantics are just not enough. Many conditions may cause a message to be undeliverable. Messages may expire before they reach their intended destination, or messages are viewed by the provider as undeliverable due to some other reason such as a deployment configuration problem. A message need not have an expiration associated with it, which means it would never expire. Forever is a long time. Realistically, it would be more prudent if the JMS provider could notify an application if a message cannot be delivered within a reasonable amount of time.

Although these issues are not specifically addressed by the JMS specification, some messaging vendors have the notion of a "Dead Letter Queue" or "Dead Message Queue" to deal with messages that are deemed undeliverable.

The extent of Dead Message Queue (DMQ) support varies from vendor to vendor. In the simplest case, it is the responsibility of the messaging system to put all undeliverable messages in the DMQ, and it is the responsibility of the application to monitor its contents. In addition, a JMS provider may support administrative events that notify the application when something is placed in the DMQ. The notification may go to the sender, or it may go to a centralized management tool. A specialized JMS client may be written to receive all DMQ notifications.

A DMQ can be treated just like a normal queue in most respects; it can be consumed, or it can be browsed. There is one respect in which a DMQ behaves differently from other queues: the destination of a message, as obtained via Message.getJMSDestination( ), would be the original destination the message was intended for, not the DMQ. The message may also contain additional properties, such as a vendor-defined reason code indicating why the message was placed in the DMQ.

It's important to know whether the JMS provider you are using supports Dead Message Queues. If it does, and you don't provide the application support to monitor it and peel things from the DMQ in a timely fashion, then the DMQ may fill up over time without your knowledge.