Message redelivery from non transacted MDBs

[timfox]

Using JBoss-4.0.5.GA.

If I throw a RuntimeException from inside the onMessage method of a MDB set to tx NotSupported, then redelivery does not occur.

The EJB2 spec is pretty silent about what should occur (17.6.3.1, 17.6.3.2) and only really says that redeliver should occur if the onMessage is running in a tx context.

For the analogous case of a RuntimeException thrown from a non MDB (straightforward jms MessageListener) onMessage method with ack mode of AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE, then the JMS 1.1 spec is pretty clear that redelivery should be immediately attempted.

It seems to me that the current MDB container behaviour is a bit weird, since you end up with messages remaining unacked in the connection consumers session until the mdb container is redeployed.

A better and more intuitive behaviour IMHO would be to attempt to redeliver the message x times then put it in the DLQ. Then at least the user can do something with it. Otherwise it is effectively lost.

I would have thought that if the EJB spec is silent about one aspect of MDB delivery behaviour we should fall back to what's specified in the JMS spec, rather than do something completely different.

Or perhaps there's a good reason why redelivery isn't attempted in this situation that I haven't thought about.

[timfox]

One other thing to note is that our redelivery behaviour differs from our competitors:
http://edocs.bea.com/wls/docs81/ejb/message_beans.html

The actual reason redelivery doesn't occur is that the MDB container which sits between the JMS provider and the customer provide onMessage implementation, catches the RuntimeException and wraps it in an EJBException.

So when it gets to the JMS provider it's no longer a RuntimeException and the JMS provider won't redeliver the message (JMS says any RuntimeExceptions should cause redelivery).

[weston.price]

Correct.

Technically, there is nothing to *force* us to redeliver the message in the case of a non specified transaction context (ie BMT, CMT NotSupported). All specs are at best ambiguous, and at worst, completely ingnorant of this subject. However, a customer requirement (not supported by me mind you) came up and this *feature* was added to the JCA adapter. This change initially was added in HEAD and then aggressively, and stupidly might I add, backported to multiple branches on the 4.x line.

After the dust cleared I went back in HEAD and reworked some of it to be more performant and easier to understand. I haven't backported these changes yet.

So, the long and short of it:

If you want redelivery in the case of BMT, CMT NotSupported you

a) Have to use JCA
b) Are encouraged, if at all possible, to use the current implementation in HEAD.