« Return to Thread: JMS Transport Retry behaviour

Re: JMS Transport Retry behaviour

by UWD :: Rate this Message:

Reply to Author | View in Thread

Hmmmm, We're using an older Mule version and this is how we've set it up:

On the JMS connector:
        <exception-strategy className="org.mule.impl.DefaultExceptionStrategy">
           <endpoint address="file://errorjms" connector="FileLogJMSConnector">
           </endpoint>
        </exception-strategy>

If a JMS message is received that has a format-error for example, our component will throw an exception, and after 2 redeliveries this happens:

15:17:28,069 ERROR org.mule.impl.DefaultExceptionStrategy [jmsConnector.Subscription.receiver.3] -
********************************************************************************
Message               : "Message with id "ID:427647BDB7AF23D764:1" has been redelivered "2" times, which exceeds the maxRedelivery setting on the connector. Message with id "ID:427647BDB7AF23D764:1" has been marked for redelivery, this usually happens after a transaction rollback. Message payload is of type: com.tibco.tibjms.TibjmsTextMessage

15:17:29,321  INFO org.mule.providers.file.FileMessageDispatcher [jmsConnector.Subscription.receiver.3] - Successfully connected to: file://errorjms

15:17:29,331  INFO org.mule.providers.file.FileMessageDispatcher [jmsConnector.Subscription.receiver.3] - Writing file to: errorjms\Error_JMS_2008-08-29.xml

The Error log contains the JMS Message and a message that the exception is an org.mule.providers.jms.MessageRedeliveredException, so it's not actually the exception that was thrown from our component.

My advice is to set an exception-strategy for the component(mule-descriptor) and model as well, and maybe see if anyone of them gets called instead...

Pete M wrote:
My mistake - its not really working.  There is no notification message.  The retry works but the exception strategy fails.  After the set number of retries nothing happens.  The exception strategy on the base connector  is being set but never gets called.  The expected exception gets logged but I just can't get a message routed with the exception in it.

It looks like I should have stuck to hand coded retries.

 « Return to Thread: JMS Transport Retry behaviour