MDL max overload exceeded

Question

I have a very simple setup for reading MULE from the HornetQ queue and saving the object to the database:

below:

<jms:connector name="connector.jms" maxRedelivery="1" connectionFactory-ref="hornetQConnectionFactory" doc:name="JMS" createMultipleTransactedReceivers="true" numberOfConcurrentTransactedReceivers="100" acknowledgementMode="AUTO_ACKNOWLEDGE"> <reconnect count="50" frequency="5000"/> </jms:connector> <flow name="jmsListenerFlow1" doc:name="jmsListenerFlow1"> <jms:inbound-endpoint queue="adsLogQueue" connector-ref="connector.jms" doc:name="JMS"> <jms:transaction action="ALWAYS_BEGIN"/> </jms:inbound-endpoint> <component > <spring-object bean="logSaver"/> </component> </flow> 

Why do I get a message that the message was re-added 9 times to the endpoint, and the value of maxRedelivery is 1? What does this mean?

hornetQConnectionFactory:

  <bean name="hornetQTransportConfiguration" class="org.hornetq.api.core.TransportConfiguration"> <constructor-arg value="org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"/> <constructor-arg> <map> <entry key="host" value="${jms.host}" /> <entry key="port" value="${jms.port}" /> </map> </constructor-arg> </bean> <bean name="hornetQConnectionFactory" class="org.hornetq.jms.client.HornetQJMSConnectionFactory"> <constructor-arg index="0" value="false"/> <constructor-arg index="1" ref="hornetQTransportConfiguration"/> <property name="minLargeMessageSize" value="250000"/> <property name="cacheLargeMessagesClient" value="false"/> </bean> 

Any help would be appreciated!

The stack trace below.

  ERROR 2012-10-19 01: 04: 07,283 [Thread-3013 (HornetQ-client-global-threads-1442093417)]: 

 Message: "Message with id" ID: e6a0b303-1977-11e2-96d4-810571a3fe10 "has been redelivered 9 times on endpoint" jms: // adsLogQueue ", which exceeds the maxRedelivery setting of 1 on the connector" connector.jms ". Message payload is of type: HornetQObjectMessage
 Code: MULE_ERROR - 2

 Exception stack is:
 1. "Message with id" ID: e6a0b303-1977-11e2-96d4-810571a3fe10 "has been redelivered 9 times on endpoint" jms: // adsLogQueue ", which exceeds the maxRedelivery setting of 1 on the connector" connector.jms ". Message payload is of type: HornetQObjectMessage (org.mule.transport.jms.redelivery.MessageRedeliveredException)
   org.mule.transport.jms.redelivery.JmsXRedeliveryHandler: 91 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/transport/jms/redelivery/MessageRedeliveredException.html)

 Root Exception stack trace:
 org.mule.transport.jms.redelivery.MessageRedeliveredException: "Message with id" ID: e6a0b303-1977-11e2-96d4-810571a3fe10 "has been redelivered 9 times on endpoint" jms: // adsLogQueue ", which exceeds the maxRedelivery setting of 1 on the connector "connector.jms". Message payload is of type: HornetQObjectMessage
     at org.mule.transport.jms.redelivery.JmsXRedeliveryHandler.handleRedelivery (JmsXRedeliveryHandler.java:91)
     at org.mule.transport.jms.MultiConsumerJmsMessageReceiver $ JmsWorker.preProcessMessage (MultiConsumerJmsMessageReceiver.java:418)
     at org.mule.transport.AbstractReceiverWorker $ 1 $ 1.process (AbstractReceiverWorker.java:120)
     + 3 more (set debug level logging or '-Dmule.verbose.exceptions = true' for everything)
 ***************************************************** ********************************

Answer 1

The first thing to note is that Mule uses the JmsXRedeliveryHandler , which means that it has found that HornetQ supports the JMS_X_DELIVERY_COUNT header and will keep track of the count of re-deliveries. In this situation, Mule relies entirely on HornetQ to ensure accurate re-delivery counts.

The fact that this exception is thrown means that the JMS message was submitted by Mule with a re-delivery count that exceeds the count configured on the JMS connector (1 in your case).

Since you are consuming the transaction, what could happen is that HornetQ will roll back and present this Mule message every time it restarts again and again, unless you have configured the maximum number of re-delivery for HornetQ itself.

My advice is: set the same re-delivery metric to Mule and HornetQ or use -1 to Mule (no limit) and rely entirely on the HornetQ delivery limit.