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?
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.