Dead Message Queues
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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access