Here is my solution - its not pretty.
I need the ActiveMQ transport to retry a configurable number of times then give up and tell me with an exception I can catch in an exception strategy.
Created a custom exception handler that overrides :
public void handleTransaction(Throwable t) and does nothing, and
public void handleMessagingException(MuleMessage message, Throwable t)
Mule seems to call handleTransaction first then handleMessagingException.
I do the work of handle transaction in the handleMessageException method.
ActiveMQ causes the handleMessageException to be called on each retry. I configure the exception strategy with the same retry count as AMQ, and examine the current retry value on the AMQ message.
If there try count is not expired I just pass the exception on up to the super class. If the has expired I replace the exception with a synthetic one indicating a retry failure. ie I replace t with a new different exception.
if (retryCounter >= (maxRetries - 1)) {
super.handleTransaction(t1);
super.handleMessagingException(message, t1);
} else {
super.handleTransaction(t);
super.handleMessagingException(message, t);
}
In the strategy configuration I control the transaction roll back and commit like :
<mule:custom-exception-strategy class="failurerecovery.CustomExceptionStrategy">
<mule:commit-transaction exception-pattern="failurerecovery.CommitException"/>
<mule:rollback-transaction exception-pattern="target.TargetServiceException"/>
<spring:property name="maxRetries" value="${service.maxretries}"/>
<spring:property name="endpoints">
<spring:list>
<spring:ref bean="my.errorhandler"/>
</spring:list>
</spring:property>
</mule:custom-exception-strategy>
This does what I need it to do.
Pete
Andrew Perepelytsya wrote:
This could be the difference between Tibco EMS and ActiveMQ. The latter had
it's own redelivery system beyond jms redeliveries, and many people have
found it confusing and often not working as expected.
Not helping, but could save some time maybe...
Andrew
