Question

If I enable transaction management on my DefaultMessageListenerContainer by specifying sessionTransacted=true or transactionManager=jmsTransactionManager, whenever an exception occurs in the MDP, the transaction is rolled back and the message is placed back on the queue. That then causes the message to be processed again, the transaction to roll back again over and over again so that it creates an endless loop.

I guess my question is … what am I missing here? Why would you want the message to go back on the queue if it just means it will be processed over and over again?

<!-- jms connection factory -->
<bean name="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:ConnectionFactory" />
</bean>

<!-- jms transaction manager -->
<bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
    <property name="connectionFactory" ref="jmsConnectionFactory" />
</bean>

<!-- Destination for Inbound_Email_Q -->
<bean name="inboundEmailDestination" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="queue/inbound_Email_Queue" />
</bean>

<!-- JmsTemplate for Inbound_Email_Q -->
<bean name="jmsInboundEmailTemplate" class="org.springframework.jms.core.JmsTemplate">
    <property name="connectionFactory" ref="jmsConnectionFactory" />
    <property name="defaultDestination" ref="inboundEmailDestination" />
    <property name="messageConverter" ref="xmlMessageConverter" />
</bean>

<!-- jms asynchronous listener -->
<bean id="emailMessageServiceMdp" class="org.site.wso.core.jms.EmailMessageServiceMdp" />
<bean class="org.springframework.jms.listener.DefaultMessageListenerContainer">
    <property name="connectionFactory" ref="jmsConnectionFactory"/>
    <!-- <property name="transactionManager" ref="jmsTransactionManager" />  -->
    <!-- <property name="sessionTransacted" value="true"/>  -->
    <property name="destination" ref="inboundEmailDestination"/>
    <property name="messageListener" ref="messageListener"/>
</bean>

<!-- jms message listener adapter -->
<bean id="messageListener" class="org.springframework.jms.listener.adapter.MessageListenerAdapter">
    <constructor-arg>
        <bean class="org.site.wso.core.jms.EmailMessageServiceMdp"/>
    </constructor-arg>
    <property name="messageConverter" ref="xmlMessageConverter"/>
</bean>

And here is my MDP:

public class EmailMessageServiceMdp implements MessageDelegate {

    public void handleMessage(Object object) {

        EmailMessageRequestVO requestVO = (EmailMessageRequestVO) object;   

        try {
            //Service call that throw exception
        } catch (Exception e) {
            throw new ApplicationException(e);
        }

    }
}

Answer 1

The message redelivery is simply the default behaviour for your [configured] JMS implementation. It’s up for endless debate what the relative usefulness of this is, but it would seem that rather than discard a message with some potentially unrecoverable data, some sort of retry is a sensible and conservative approach. For example, in your case, you appear to be converting a JMS message to an email message and dispatching to an SMTP server. If the SMTP gateway is down, you might want to hold onto the JMS messages and reprocess them when the gateway comes back up.

In general I would say your options for handling a message that failed processing are (depending on the JMS implementation):

1. Ditch the message.
2. Write the message to an error queue.
3. Redeliver the message after a delay of n seconds.
4. Redeliver the message n times and then write the message to an error queue.
5. Redeliver the message after a delay of n seconds x times and then write the message to an error queue.

If you prefer #1, then simply suppress the exception, commit the transaction and wave good bye to the message. For the rest, the JMS configuration (or the destination specific configuration) should handle those.

Additionally, if you want something more specific, you can interrogate the message’s getJMSRedelivered() and/or the implementation specific message header property that indicates how many times the message has been redelivered (supported by most JMS implementations, but not standard) and dispose of the message accordingly.