0
votes

We have a scenario where we are using Mule (Version 3.4 - old, I know) to rollback a JMS transaction after a catch exception. ActiveMQ should keep the message on the queue (to make persistent) until the transaction is committed, or redeliver as per the rollback settings after a Mule initiated rollback.

However, it seems like after a rollback, the message is not redelivered and sits on the queue connection "blocking" further messages. It is as if the rollback message is not received. Does anyone have any idea why this would not be returned?

Extract from logs:

2017-03-29 11:23:26,345 [Session Task-16] DEBUG SingleResourceCollectionTransaction - Rolling back a transaction collection in the following order: [org.mule.transport.jms.JmsTransaction@bea1685a-1469-11e7-9d1d-5ba5419e6645[status=STATUS_MARKED_ROLLBACK, key=ActiveMQConnection {id=ID:serveradd-50176-1490782511241-3:1,clientId=ID:serveradd-50176-1490782511241-2:1,started=false}, resource=org.mule.transport.jms.ReusableTopicSessionWrapper@c2149e58]]
2017-03-29 11:23:26,345 [Session Task-16] DEBUG SingleResourceCollectionTransaction - Rolling back transaction
2017-03-29 11:23:26,345 [Session Task-16] DEBUG g.mule.transport.jms.JmsTransaction - Rolling back transaction
2017-03-29 11:23:26,345 [Session Task-16] DEBUG g.mule.transport.jms.JmsTransaction - Rolling back transaction: bea1685a-1469-11e7-9d1d-5ba5419e6645
2017-03-29 11:23:26,345 [Session Task-16] DEBUG org.apache.activemq.ActiveMQSession - ID:serveradd-50176-1490782511241-3:1:6 Transaction Rollback, txid:TX:ID:serveradd-50176-1490782511241-3:1:21
2017-03-29 11:23:26,345 [Session Task-16] DEBUG .apache.activemq.TransactionContext - Rollback: TX:ID:serveradd-50176-1490782511241-3:1:21 syncCount: 1
2017-03-29 11:23:26,346 [Session Task-16] DEBUG transaction.TransactionCoordination - Unbinding transaction (14) com.mulesoft.mule.transaction.SingleResourceCollectionTransaction@bea11a39-1469-11e7-9d1d-5ba5419e6645[status=STATUS_ROLLEDBACK, key=null, resource=null]
2017-03-29 11:23:26,346 [Session Task-16] DEBUG n.InterceptingChainLifecycleWrapper - Invoking InterceptingChainLifecycleWrapper 'wrapper for null' 
[ 
  org.mule.api.processor.LoggerMessageProcessor@7e9d1d0b
] with event MuleEvent: 0-bea2c7f2-1469-11e7-9d1d-5ba5419e6645, stop processing=false, jms://myQueue
2017-03-29 11:23:26,347 [Session Task-16] DEBUG .chain.DefaultMessageProcessorChain - Invoking DefaultMessageProcessorChain '(inner iterating chain) of null' 
[ 
  org.mule.api.processor.LoggerMessageProcessor@7e9d1d0b
] with event MuleEvent: 0-bea2c7f2-1469-11e7-9d1d-5ba5419e6645, stop processing=false, jms://myQueue
2017-03-29 11:23:26,347 [Session Task-16] INFO  pi.processor.LoggerMessageProcessor - Rolling back...
2017-03-29 11:23:26,347 [Session Task-16] DEBUG .support.DefaultListableBeanFactory - Returning cached instance of singleton bean '_muleStreamCloserService'
2017-03-29 11:23:26,347 [Session Task-16] DEBUG .support.DefaultListableBeanFactory - Returning cached instance of singleton bean '_muleStreamCloserService'
2017-03-29 11:23:26,347 [Session Task-16] DEBUG ule.util.DefaultStreamCloserService - Unable to find an StreamCloser for the stream type: class net.MyBean, the stream: net.MyBean@e341f050 will not be closed.
1

1 Answers

0
votes

I have no working knowledge on Mule, but, since it is JMS/J2EE I would check the redelivery option the mule queue. There is a property on it to make the N number of attempts before sending the fail message to the dead letter queue(i know activemq has it).