How to get retry count from ActiveMQ Artemis message - apache-camel

Question

I'm taking the message from an ActiveMQ Artemis queue and trying to send it to an invalid HTTP endpoint (through a Camel route) it fails and the message gets retried. Whenever message delivery fails it gets retried at ActiveMQ Artemis level. Retry configuration is available in broker. Is there any way to get current retry count for a JMS message in client applications?
I can maintain retry count in DB per message - looking for better solution / existing methods etc.
If I try to maintain the count and set it in the message header then during retry those get lost. Retry happens as if it's a new message. So can't use it.
We are using org.apache.camel.component.jms.JmsComponent with the Qpid JMS client.

Answer 1

You should inspect the JMSXDeliveryCount property on the message. Section 3.5.9 of the JMS 1.1 specification says this about JMSXDeliveryCount:
The number of message delivery attempts; the first is 1, the second 2,...
I just tested this with Qpid JMS 1.7.0 and ActiveMQ Artemis 2.27.1 and it worked fine in both transacted and non-transacted use-cases. In both cases the JMSRedelivered header and the JMSXDeliveryCount property were set appropriately.
Here's the code for the transacted use-case:
try (Connection connection = new JmsConnectionFactory("amqp://127.0.0.1:5672").createConnection()) {
Session session = connection.createSession(true, Session.CLIENT_ACKNOWLEDGE);
Queue queue = session.createQueue("myQueue");
MessageConsumer consumer = session.createConsumer(queue);
MessageProducer producer = session.createProducer(queue);
TextMessage message = session.createTextMessage("test-message");
producer.send(message);
session.commit();
producer.close();
connection.start();
message = (TextMessage) consumer.receive(1000);
System.out.println("Redelivered? " + message.getJMSRedelivered());
System.out.println("Delivery count: " + message.getIntProperty("JMSXDeliveryCount"));
message.acknowledge();
session.rollback();
message = (TextMessage) consumer.receive(1000);
System.out.println("Redelivered? " + message.getJMSRedelivered());
System.out.println("Delivery count: " + message.getIntProperty("JMSXDeliveryCount"));
}
Here's the code for the non-transacted use-case:
try (Connection connection = new JmsConnectionFactory("amqp://127.0.0.1:5672").createConnection()) {
Session session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
Queue queue = session.createQueue("myQueue");
MessageConsumer consumer = session.createConsumer(queue);
MessageProducer producer = session.createProducer(queue);
TextMessage message = session.createTextMessage("test-message");
producer.send(message);
producer.close();
connection.start();
message = (TextMessage) consumer.receive(1000);
System.out.println("Redelivered? " + message.getJMSRedelivered());
System.out.println("Delivery count: " + message.getIntProperty("JMSXDeliveryCount"));
session.close();
session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);
consumer = session.createConsumer(queue);
message = (TextMessage) consumer.receive(1000);
System.out.println("Redelivered? " + message.getJMSRedelivered());
System.out.println("Delivery count: " + message.getIntProperty("JMSXDeliveryCount"));
}
In both cases this is what was printed:
Redelivered? false
Delivery count: 1
Redelivered? true
Delivery count: 2
The behavior you're seeing with the message being redelivered as "a new message" is expected. As noted in section 3.10 of the JMS 1.1 specification:
A consumer can modify a received message after calling either the clearBody or clearProperties method to make the body or properties writable. If the consumer modifies a received message, and the message is subsequently redelivered, the redelivered message must be the original, unmodified message (except for headers and properties modified by the JMS provider as a result of the redelivery, such as the JMSRedelivered header and the JMSXDeliveryCount property).
I'm not a Camel expert so I can't say exactly is Camel doing with the JMS message when delivery to the HTTP endpoint fails. All I know is that this works fine with straight JMS. I would expect this to work with Camel also, but Camel may be doing their own form of retry rather than using the redelivery which JMS provides.
This would be relatively trivial to validate by turning on AMQP frame tracing from the Qpid JMS client and inspecting the frames around message delivery and the resulting disposition.