1

Is there a way to explicitly tell the broker to send a message to the queue's assigned dead letter queue?

I know we can configure a queue to automatically send messages to the DLQ after a certain number of re-delivery attempts. That makes perfect sense for transient errors such as database issues, network issues, etc. However in the case of a business rule error, it doesn't make sense to have that message attempt redelivery X number of times over X number of minutes before being sent to the dead letter queue when we know it's a business rule violate / malformed message, etc.

I was hoping there was a way that when we catch a business rule violation we can immediately send it to that queues dead letter queue. I know I could explicitly write the code to send it to that dead letter queue but we will have many (dozens) of configurable queues and their associated dead letter queues will be configured by our middleware team. I don't want to explicitly code the dead letter queue queue names or even configure them in my own properties. I'm hoping there is a simple way to tell the broker to immediately send the message to the dead letter queue and not attempt redelivery.

It seems like it should be something like message.deadLetter(). I feel like I must be missing something simple but I don't see any mechanism like that on the consumer, session or message.

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
Todd Johnson
  • 147
  • 1
  • 11

1 Answers1

0

There is no accommodation for the feature you're describing in the JMS specification. The JMS spec incorporates redelivery via things like the JMSRedelivered header and JMSXDeliveryCount property. However, it actually makes no mention of "dead-letter" destinations.

That said, such a feature might be provided by a particular JMS broker, but since you don't mention what JMS broker implementation you're using it's impossible to say whether your chosen broker implements such a feature. In any case, it would be configured and/or invoked via an implementation-specific mechanism that would be, by definition, non-portable between brokers and not available from the JMS API.

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
  • Thanks for the confirmation Justin. It's very surprising to me this doesn't exist. Is there anyway, programmatically in JMS, to find the dead-letter-queue associated to a queue? That way I could move the message myself. With configuration and control of the queues being managed by a separate team I cannot make any assumptions about the DLQ. I must be able to programmatically look it up. I've looked through the JMS API and cannot see anyway to do this either, but I'm just trying to confirm I'm not missing anything simple. – Todd Johnson Feb 18 '22 at 18:48
  • I agree that such a feature makes sense, but JMS just doesn't support it. As noted, the spec doesn't cover "dead letter" destinations. There's no provision in the specification for associating a "dead letter" destination with another destination, and therefore no API calls to perform a look-up to ascertain such an association. – Justin Bertram Feb 18 '22 at 19:09
  • What JMS broker are you using? It might have an implementation-specific way of doing what you want if you're willing to bake some non-portable code into your application. – Justin Bertram Feb 18 '22 at 19:24
  • Thank you again Justin! I can see I have a few options to handle this through the broker's (Artemis) proprietary API but really wanted to avoid. that. You may be wondering why this is such a big problem for me. Our clients fine us many thousands of dollars per minute when we have a service interruption. So in the case of non-transient errors, we want those in the DLQ immediately so our support staff can address them.. We cannot accept unnecessary retries. Unnecessarily retrying for 20 minutes could result in a $100,000 charge-back if it impacted the client's production. – Todd Johnson Feb 18 '22 at 19:34
  • Your use-case makes perfect sense. I work on ActiveMQ so let me know if there's anything you think which could be done to make this easier. In the future maybe something like this could be incorporated into Jakarta Messaging (i.e. the replacement for JMS). – Justin Bertram Feb 18 '22 at 19:59