Auto-acknowledge, Exceptions and Re-queueing

[dtauzell]

I have an MDB running in 3.0 and is using MQSeries as the JMS provider.

The way we using MQSeries (client mode) does not allow XAQueueConnectionFactories. So, I have set the bean descriptor to have:

Transaction Mode: Bean
Acknowledge Mode: Auto-acknowledge

I expect that if an EJBException is thrown during execution of my bean's onMessage() method that the message will not be acknowledged and will be re-queued.

This doesn't seem to be happening. Any ideas?

[joelvogt]

Your onMessage method should not be throwing any exceptions. You should catch anything that might go wrong and ask the message to be resent manually.

[mevans7]

How do you "ask the message to be resent manually"?

[genman]

If you set the MDB to auto-acknowledge, then the message will be acknoledged just before the onMessage method is called. Thus, there is no way to retry the message. This is just follows how the specification was originally designed for MDB.

My suggestion is that you get container managed transactions to work. If your database doesn't support XA transactions, I have a work-around.

[mevans7]

I have a MDB task and this forum message seemed to relate. Here's my actual situation and need.

I want a MDB that reads a JMS queue. The bean makes a session bean call. (That call is dependent on an Oracle database being up and running.) If that bean call fails with the need to retry, I don't know the mechanism for "not acknowledging" the message, or somehow getting it to be retried. Should I just have the MDB wait a short time and try the send again? Is there some way to not acknowledge the message in a manner that it will be retried later?

I'm guessing this situation is not uncommon. Any recommendations?

Thanks,
Mark

[genman]

Well, you can "rollback" the message using the MessageDriven Context. Unfortunately, the message will soon be resent to your MDB, as you probably know, and likely fail again. My suggestion is to Thread.sleep a useful amount and then rollback the message.

[spohl]

That would be interesting for me too. How can the suspended Container transaction (that dequeued the message) be hinted NOT to acknowledge the receipt so that it will be resend?

In 15.4.13 the EJB spec 2.1 says expressly: "If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the Container should not acknowledge the message."

Something for the todo list for J2EE compliance? :-)

Regards.

[spohl]

Sorry, please excuse my double post.

"spohl" wrote:
That would be interesting for me too. How can the suspended Container transaction (that dequeued the message) be hinted NOT to acknowledge the receipt so that it will be resend?

In 15.4.13 the EJB spec 2.1 says expressly: "If a message-driven bean uses bean-managed transaction demarcation and throws a RuntimeException, the Container should not acknowledge the message."

Something for the todo list for J2EE compliance? :-)

Regards.