Activemq How to open the dead letter queue

In the following three scenarios, the ACTIVEMQ message is sent back to the client/consumer:
1. Use a transaction session, and call the rollback () method;
2. A transaction session, a commit was called before closing;

3. The Client_acknowledge signature mode is used in the session, and the Session.recover () method is called.

The broker uses the Brokerinfo command package to establish a connection to the client and transmits the default send policy to the clients according to its own rules. However, the client can override this policy setting using the Activemqconnection.getredeliverypolicy () method.
Java Code Collection Code
Redeliverypolicy policy = Connection.getredeliverypolicy ();
Policy.setinitialredeliverydelay (500);
Policy.setbackoffmultiplier (2);
Policy.setuseexponentialbackoff (TRUE);
Policy.setmaximumredeliveries (2);

The XML configuration is as follows

Once the message resend attempt exceeds the maximumredeliveries configured in the Resend policy (the default is 6), a "Poison ack" is sent to the broker informing it that the message is considered a poison pill (a Poison pill), The broker then sends this message to the DLQ (Dead letter Queue) for subsequent analysis processing.


The default Badmail queue (Dead letter queue) is called ACTIVEMQ.DLQ, and all undeliverable messages are sent to this queue, which can be very difficult to manage. You can set the "Individualdeadletterstrategy" property of the destination policy map in the Activemq.xml file to modify it.

Opening the dead-letter queue must be enabled when things are turned on

The listen code is as follows

public class Defaultmessagelistener implements MessageListener {private static Logger Logger = Loggerfactory.getlogger (

	"Activemqlog");

	Private Ryzhmessagereceiver receiver;
		public void OnMessage (Message message) {Logger.info ("Defaultmessagelistener personnel integration: Consumers start consuming");
		ObjectMessage objectmessage = (objectmessage) message;
		Ryzhmessage ryzhmessage = null;
			try {ryzhmessage = (ryzhmessage) objectmessage.getobject ();
			Receiver.receive (Ryzhmessage);
			int a =1/0;
			Confirm Message Receipt//Logger.info without error ("Defaultmessagelistener Personnel integration: Consumer consumption success 1111111111111111111");
			throw new JMSException ("process failed");
			Objectmessage.acknowledge ();
		Logger.info ("Defaultmessagelistener personnel integration: Consumer consumption success"); } catch (Exception e) {logger.error ("Defaultmessagelistener personnel consolidation: abnormal Shcemeid When consumer consumption:" + Ryzhmessage.getshcemeid (), E)
			;
		Throw Jmsutils.convertjmsaccessexception (New JMSException (E.getmessage ()));
	}} public Ryzhmessagereceiver Getreceiver () {return receiver; } publicvoid Setreceiver (Ryzhmessagereceiver receiver) {this.receiver = receiver; }

}

The sender code is as follows

<span style= "color: #666666;" >public void Send (Final ryzhmessage ryzhmessage) {
		//Get MQ Tool class
		Ryzhmqholder Hodler = Mqholders.get ( Ryzhmessage.getshcemeid ());
		Send Information
		jmstemplate.setconnectionfactory (cachingproductconnectionfactory);
		Jmstemplate.send (Hodler.getdestination (), new Messagecreator () {public
			Message CreateMessage (Session session) Throws JMSException {
				ObjectMessage objectmessage = Session.createobjectmessage ();
				Objectmessage.setobject (ryzhmessage);
				</span><span style= "color: #ff0000;" >objectmessage.setjmsredelivered (TRUE);//Message re-</span><span style= "color: #666666;" >
				return objectmessage;}}
		);
	} </span>

The effect is shown by default to the death queue sent to ACTIVEMQ.DLQ, and after modifying the MQ configuration, it is sent to the death queue with DLQ. Start + original queue name.

This time the original queue shows that the change message has been consumed, actually sent to the death queue inside