jmsspring-jmsactivemq-artemis

ActiveMQ Artemis message is lost


I am using ActiveMQ Artemis 2.27.1 from my Spring Boot application. I see that a producer publishes message to a queue, but the consumer is not called even once and the message is sent to the DLQ. This happens for one in 1,000 records.

Following this the message in console:

[org.apache.activemq.artemis.core.server] AMQ222149: Sending message Reference[136935621524]:RELIABLE:CoreMessage[messageID=136935621524,durable=true,userID=ee4ae038-34b3-11f0-afd8-d6646541f91b,priority=4, timestamp=Mon May 19 13:19:45 UTC 2025,expiration=0, durable=true, address=oor::p1.queue,size=1602,properties=TypedProperties[__AMQ_CID=ee4a6b05-34b3-11f0-afd8-d6646541f91b,_AMQ_ROUTING_TYPE=1,JMSCorrelationID=2b6a921fc052c65c]]@1108437122 to Dead Letter Address DLQ from p1.queue

How can I know the exact reason why its here?

Also I tried to listen the DLQ as:

@JmsListener(destination = "DLQ", containerFactory = "jmsListenerContainerFactory")
@Monitored
public void handleDlq(Message message) throws JMSException {
    log.info(" DLQ Message listen: {}", message);

However, the listener is not called.

JMS Config :

@Configuration
public class JmsConfig {
    
    @Bean
    public JmsListenerContainerFactory<?> jmsListenerContainerFactory(ConnectionFactory connectionFactory) {
        DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
        factory.setConnectionFactory(connectionFactory);
        factory.setSessionAcknowledgeMode(Session.CLIENT_ACKNOWLEDGE);
        factory.setConcurrency("1-5");
        return factory;
    }

broker.xml:

         <!--default for catch all-->
         <address-setting match="#">
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>

            <!-- if max-size-bytes and max-size-messages were both enabled, the system will enter into paging
                 based on the first attribute to hits the maximum value -->
            <!-- limit for the address in bytes, -1 means unlimited -->
            <max-size-bytes>-1</max-size-bytes>

            <!-- limit for the address in messages, -1 means unlimited -->
            <max-size-messages>-1</max-size-messages>

            <!-- the size of each file on paging. Notice we keep files in memory while they are in use.
                 Lower this setting if you have too many queues in memory. -->
            <page-size-bytes>10M</page-size-bytes>

            <!-- limit how many messages are read from paging into the Queue. -->
            <max-read-page-messages>-1</max-read-page-messages>

            <!-- limit how much memory is read from paging into the Queue. -->
            <max-read-page-bytes>20M</max-read-page-bytes>

            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>PAGE</address-full-policy>
            <auto-create-queues>true</auto-create-queues>
            <auto-create-addresses>true</auto-create-addresses>
            <auto-delete-queues>false</auto-delete-queues>
            <auto-delete-addresses>false</auto-delete-addresses>
         </address-setting>

I see these warnings as well:

2025-05-19 12:29:06,881 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session 2a0822a2-348b-11f0-aa3b-9676b57d7c3c
2025-05-19 12:29:06,881 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session 2a093413-348b-11f0-aa3b-9676b57d7c3c
2025-05-19 12:29:06,881 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session 2a093413-348b-11f0-aa3b-9676b57d7c3c
2025-05-19 12:29:06,881 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session 2a0ed964-348b-11f0-aa3b-9676b57d7c3c

Help me identify why the message goes to the dead letter queue without being retried.


Solution

  • It's very likely that the connection failures noted in the log are directly related to the messages being sent to the dead-letter address.

    In this case the broker would have dispatched the message to the consumer and the consumer would have received it, but since it is using CLIENT_ACKNOWLEDGE mode it would have failed to acknowledge the message before the connection failed. This would increase the delivery attempts and would eventually lead the message to be sent to the dead-letter address.

    The connection might be lost due a network failure, client crash, etc. You'll need to do some root-case analysis in your environment to determine why the connection failed.