未创建ActiveMQ死信队列

Question

I'm trying to use configure and test ActiveMQ dead letter queue, but I have some issue. As in official docs said:

When messages expire on the Active MQ broker (they exceed their time-to-live, if set) or can't be redelivered, they're moved to a dead-letter queue, so they can be con- sumed or browsed by an administrator at a later point. Messages are normally redelivered to a client in the following scenarios:

1. A client is using transactions and calls rollback() on the session.
2. A client is using transactions and closes before calling commit.
3. A client is using CLIENT_ACKNOWLEDGE on a session and calls recover() on that session.

So, I've made my Producer class to create transactional session and rollback transaction after message is sent. As I expected, message didn't appear in the destination queue, but trouble is that DLQ wasn't created at all. How can I manage dead letter queue? I can't find it using JConsole - there is only destination queue, but not a DLQ.

Do you know where trouble is? There are Producer.java and Spring config!

<bean id="producer" class="com.jmsexamples.Producer">
    <property name="connectionFactory" ref="jmsFactory" />
    <property name="destination" ref="queue" />
    <property name="login" value="roman" />
    <property name="password" value="sawawluha" />
</bean>

<bean id="consumer" class="com.jmsexamples.Consumer">
    <property name="connectionFactory" ref="jmsFactory" />
    <property name="destination" ref="queue" />
    <property name="login" value="roman" />
    <property name="password" value="sawawluha" />
</bean>

<bean id="jdbc_ds" class="org.apache.commons.dbcp.BasicDataSource"
    destroy-method="close">
    <property name="driverClassName" value="com.mysql.jdbc.Driver" />
    <property name="url"
        value="jdbc:mysql://localhost:3306/ActiveMQ?relaxAutoCommit=true" />
    <property name="username" value="root" />
    <property name="password" value="" />
    <property name="poolPreparedStatements" value="true" />
</bean>

<amq:connectionFactory id="jmsFactory" brokerURL="tcp://localhost:6616" />

<amq:queue id="queue" physicalName="message.queue" />


<amq:broker id="msgBroker" persistent="true">
    <amq:persistenceAdapter>
        <amq:kahaDB directory="target/activemq-data/kahadb"
            journalMaxFileLength="16mb" />
    </amq:persistenceAdapter>

    <amq:plugins>
        <amq:loggingBrokerPlugin logAll="true" />
    </amq:plugins>


    <amq:destinationPolicy>
        <amq:policyMap>
            <amq:policyEntries>
                <amq:policyEntry queue=">">
                    <amq:deadLetterStrategy>
                        <amq:individualDeadLetterStrategy
                            queuePrefix="DLQ." useQueueForQueueMessages="true"
                            processNonPersistent="true" />
                    </amq:deadLetterStrategy>
                </amq:policyEntry>
            </amq:policyEntries>
        </amq:policyMap>
    </amq:destinationPolicy>

    <amq:transportConnectors>
        <amq:transportConnector name="openwire"
            uri="tcp://localhost:6616" />
    </amq:transportConnectors>
</amq:broker>

Producer:

public class Producer {

    private String login;
    private String password;

    private ConnectionFactory connectionFactory;

    private Destination destination;

    public void setConnectionFactory(ConnectionFactory conFact) {
        this.connectionFactory = conFact;
    }

    public void setDestination(Destination dest) {
        this.destination = dest;
    }

    public void setLogin(String login) {
        this.login = login;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public void sendMessage(int count) {

        Connection connection = null;
        Session session = null;

        try {
            System.out.println("Loggining as " + login);

            // it's not neccessary to set login and password in this example
            // but when you are running a normal message server, you should use
            // login and password for authentification
            connection = connectionFactory.createConnection(this.login,
                    this.password); // estabilishing connection
            session = connection.createSession(true, Session.AUTO_ACKNOWLEDGE); // starting
                                                                                // session
            MessageProducer producer = session.createProducer(destination); // initializing
                                                                            // of
                                                                            // message
                                                                            // producer
            System.out.println("Client_acknowledge " + session.getTransacted());
            for (int i = 0; i < count; i++) {
                TextMessage message = session.createTextMessage();

                message.setText("This is text message!");
                producer.send(message);
                System.out.println("message sent #" + i);
                session.rollback();
            }

        } catch (JMSException e) {
            e.printStackTrace();
        } finally {
            try {
                session.commit();
                session.close();
                connection.close();
                System.out.println("successfull");

            } catch (Exception e) {
                e.printStackTrace();
            }

        }
    }
}

Thanks for your help!

Answer 1

Messages sent from a producer in a TX that is rolled back will not be sent to the dead letter queue. These types of messages are considered to have never been published so they are not candidates for DLQ'ing. Since your client has decided to roll back the TX those messages it is up to your client to do something about it.

Answer 2

From a producer side - the message won't end up in DLQ if the session is rolled back.

The point of DLQ is to have "a way out" with problematic messages without loosing any data. The producer is supposed to know what to send. If the send transaction is rolled back, the message should never reach the broker. The transactional consumer will make sure a "poison message" ends up on DLQ so it won't block further incoming messages.

In the normal scenario, a transaction on the producer does not really do much. If you want to produce a set of messages at a given moment, you can produce in a transaction to have a "all or nothing" behavior.