0

I have a java client that processes messages from HornetQ. The processing may fail due to temporary network problems, which I handle by throwing an exception and configuring the queue to attempt re-delivery.

However, processing may fail due to other reasons that mean it's not worth attempting re-delivery.

Now, I could prevent re-delivery by not throwing an exception and letting the client consume the message. But I don't want to do this. I would like some way of rejecting the message and, in effect, saying to the queue: "don't bother re-delivering this message - it can go straight to the dead-letter-queue".

Is there any way of doing this?

BillyBadBoy
  • 552
  • 3
  • 18

2 Answers2

0

Interesting idea. I'm fairly sure that this is not supported. If you rollback the redelivery settings apply and if you commit the message is consumed.

What you can do is to process the message in a new transaction. That will either succeed or fail. If it fails you can check the exception and decide what you want to do. If you think it is transient you can rollback the outer/original transaction and get a redelivery. If you want the message to go to the dead letter queue you can post it manually and then commit the outer transaction. That way you can also differentiate the dead letter queues for technical errors and functional errors if you wish.

The disadvantage (except for complexity) is that the inner transaction may commit and the outer fail for some reason. In that case you will get duplicates, so you need to make sure that you can handle that.

ewramner
  • 5,810
  • 2
  • 17
  • 33
  • Thanks - I had a hunch that what I wanted wasn't possible. I was hoping I wouldn't have to manually post to the DLQ - this kinda feels wrong. Maybe I could not redeliver at all from my main queue, and then handle transient failures by forwarding them to a second 're-delivery queue'. – BillyBadBoy May 11 '18 at 08:38
0

In Enterprise Integration Patterns there is a distinction between messages that cannot be delivered by the system: Dead Letter Channel, implemented as Dead Letter Queue in most JMS implementations, and messages that are invalid: are delivered and your app rejects them because are invalid at a logical level. Those would go to a specific Invalid Message Channel

So, in your case, in the DLQ you would have those messages that due to network problems couldn't be delivered after all the redelivery attempts. And you should define an Invalid Message Queue, to send the messages that your app thinks that are invalid.

areus
  • 2,880
  • 2
  • 7
  • 17