spring jms message recovery mechanism

[joerobles]

Hi all,

I have Spring JMS/MDPs running in a standalone/non-J2EE enviornment listening to the queue that is deployed in a J2EE enviornment.

How does Spring handle the the following scenarios:

1) where in errors like java.lang.OutofMemory errors occur while processing the message from the queue. Will the message still exist on the queue?

2) Also what happens to the message in case there is an RuntimeException thorwn while processing it and at the same time for some reason the J2EE enviornment in which the queue is present has crashed... is there a way to put the message back on the queue or is the message lost?

Any input is highly appreciated.

Thanks in advance.

Any input is highly appreciated.

[Marten Deinum]

There is not really an easy answer to that, because it depends. It depends on your JMS provider and ifyou have stateful queue/topic, it depends if you are transactional. And a combination of those. So not really a generic answer can be given.

[joerobles]

Thank you for the prompt reply.

Yes, the queue is durable ( has a perssitence store which a database table) and is transactional.

The spring MDP/Listener is currently not transacation aware. Does it have to be in order to avoid the mentioned error scenarios. If so, which transactionmanager is useful? Also will the transaction rollback in case of a java.lang.Error scenario?

Any input related tot he message recovery is highly appreciated.

Thanks in advance.

[Marten Deinum]

If the queue is durable the message will still be there if you use transactions (at least that should be the case with a decent JMS implementation). Ifyou want rollback you will have to use transactions if not there is basically no garantuee, soyou will have to make it transactional, which tx manager to use depends on your own situation.

What happens in case of Error are fatal by design and will probably kill your application, now if you use transactions and the message has not been processed again it should still be there. But again that may vary depending in JMS provider.

I suggest a few simple testcases and well you know...

[joerobles]

Hi

Thank you for the reply.

I tested in the case of java.lang.exceptions that observed that the message is removed from the persistaence store as soon as MessageListener.onMessage() starts executing. In case of any Exception, the message is lost and thus we use Spring JmsTempalte102.send() to put the message back on the weblogic queue.

In the case of java.lang.Errors ( JVM and non JVM errors), can I inject JTAtransactionManager to org.springframework.jms.listener.DefaultMessageLis tenerContainer that we are currently using in the standalone enviornment?

So that this way, the transaction is rolled back in case of any abnormal exceptions happened in the standalone enviornment and thus the message is out back on the weblogic queue??

Any input is appreciated.

Thanks in advance.

[Marten Deinum]

Why would you need a JTA tx manager in a standalone environment? Also what happens on Exceptions is based on your configuration, by default RuntimeExceptions will do a Rollback, checked exceptions need configuration (as per EJB spec) and this is also explained in the tx section of the reference guide.

As I already stated what happens for Errors depends errors are fatal by design (OutOfMemory for instance) and are probably unrecoverable.