Unexpected redelivery behaviour in ActiveMQ JMS Connector

• User impact:

  Medium
• Configuration:

  Hide

  <service name="TransactionOnInboundOnly">
  <inbound>
  <jms:inbound-endpoint queue="FromTest02" transformer-refs="JMSToObject" synchronous="false">
  <jms:transaction action="ALWAYS_BEGIN" timeout="15000"/>
  </jms:inbound-endpoint>
  </inbound>
  <outbound>
  <pass-through-router>
  <file:outbound-endpoint path="./FromJMS" outputPattern="${OUTPUTPATTERN}" synchronous="false"/>
  </pass-through-router>
  </outbound>
  </service>

  Show

  <service name="TransactionOnInboundOnly"> <inbound> <jms:inbound-endpoint queue="FromTest02" transformer-refs="JMSToObject" synchronous="false"> <jms:transaction action="ALWAYS_BEGIN" timeout="15000"/> </jms:inbound-endpoint> </inbound> <outbound> <pass-through-router> <file:outbound-endpoint path="./FromJMS" outputPattern="${OUTPUTPATTERN}" synchronous="false"/> </pass-through-router> </outbound> </service>
• Log Output:

  Attached as log file
• Similar Issues:

  None

See config for this.

I send a message on the inbound JMS queue which starts a transaction; once the message hits the outbound endpoint (which cannot participate in the transaction) the transaction is rolled back. This is the expected behaviour and with Mule 2.1, those were the results I used to get.

With Mule 2.2.1 I get different results. Tracing the transaction and endpoint-message notifications, I notice the following:

1) With both versions, the first notification is transaction_BEGAN
2) With both versions, the 2nd notification is MESSAGE_DISPATCHED
3) With both versions, the 3rd notification is MESSAGE_RECEIVED
4) With both versions, the 4th notification is TRANSACTION_ROLLEDBACK
With Mule 2.2.2, there are some more notifications:
5) TRANSACTION_BEGAN
6) MESSAGE_RECEIVED
7) TRANSACTION_ROLLEDBACK

I dug deeper and noticed that the message used in (6) above is identical to the first one except that the JMSRedelivery property is set to true. I set maxRedelivery="0" in my config thinking that the default had changed but this was not it.

Digging into the source, I found this in ActiveMqJmsConnector (line 73):

// redelivery = deliveryCount - 1, but AMQ is considering the first delivery attempt as a redelivery (wrong!). adjust for it
setMaximumRedeliveriesMethod.invoke(redeliveryPolicy, getMaxRedelivery() + 1);

Thinking that perhaps Mule is over-compensating, I set maxRedelivery="-1" and got the results I expected.

Note: Apart from the over-compensation, I don't think I should be allowed to set this attribute to a value less than zero ...