messagebean can't call setRollbackOnly 2.4.0BETA

[panz]

When calling setRollbackOnly from a message bean, i get an infinite loop in which the following exception is thrown:

[TestModule] TRANSACTION ROLLBACK EXCEPTION:null; nested exception is: javax.ejb.EJBException
[TestModule] java.lang.IllegalStateException: MessageDriven bean is not allowed to call setRollbackOnly with this transaction settings
[TestModule] at org.jboss.ejb.MessageDrivenEnterpriseContext$MessageDrivenContextImpl.setRollbackOnly(MessageDrivenEnterpriseContext.java:163)
[TestModule] at TestModule.onMessage(TestModule.java:36)

Looking at the jboss code i see the following:


public void setRollbackOnly()
{
if (((MessageDrivenMetaData)con.getBeanMetaData()).getAcknowledgeMode() != MessageDrivenMetaData.CLIENT_ACKNOWLEDGE_MODE) {
// NO transaction
Logger.log("MessageDriven bean is not allowed to call setRollbackOnly with this transaction settings");
throw new IllegalStateException("MessageDriven bean is not allowed to call setRollbackOnly with this transaction settings");
}else {
super.setRollbackOnly();

}
}

I'm confused by the (apparent) requirement that the bean use CLIENT_ACKNOWLEDGE_MODE. I assume this metadata refers to the acknowledge mode set in the ejb-jar. But client acknowledge is not a valid option according to the DTD and spec!

My deployment descriptors, etc. look essentially like the JMS examples. I can post them if asked, but i thought i'd first see if somebody could explain what's going on above.

[pra]

If I remember correct, the example from the manual is about a MDB with container managed TX:

The type of error you get should only ever happen with bean managed TX MDB (getAcknowledgeMode() != MessageDrivenMetaData.CLIENT_ACKNOWLEDGE_MODE)

No, CLIENT_ACKNOWLEDGE_MODE, is not something you may set in the dep descriptor, it is used internaly in the container.

Är you using bean managed TX?

//Peter

[panz]

No, i'm not (intentionally :) using BMT.
The bean deploys properly on weblogic using CMT. (But who wants to use weblogic?)

My ejb-jar looks like this:

<message-driven>
<display-name>TestModule</display-name>
<ejb-name>TestModule</ejb-name>
<ejb-class>...TestModule</ejb-class>
<transaction-type>Container</transaction-type>
<message-driven-destination>
<destination-type>javax.jms.Queue</destination-type>
</message-driven-destination>
...
</message-driven>
...
<assembly-descriptor>
<container-transaction>

<ejb-name>TestModule</ejb-name>
<method-name>*</method-name>

<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>

jboss.xml looks like:
<message-driven>
<ejb-name>TestModule</ejb-name>
<configuration-name>Standard Message Driven Bean</configuration-name>
<destination-jndi-name>queue/testModuleQueue</destination-jndi-name>
</message-driven>

[pra]

Hi, OK should I say congrats or I am sorry? You have actually discovered a bug in the MDB container.

This has been fixed in the main branch, but when it will find it's way into 2.4.0 I do not know.

(The only fix for now is not to use setRollbackOnly, but to throw an EJBException - which will do exactly the same thing).

I am sorry to have caused this, because it is my fault.

//Peter

[panz]

Ok. I guess that's a dubious honor.

Is the fix complex, or is there a straightforward issue that a rookie such as myself may be able to address?

Is there a workaround, or is it just not possible to transactionally send messages from an MDB at this point?

[pra]

It's pretty easy to fix (browse the CVS and make diffs and you get the picture.

It should however work under the following conditions:

- A bean wich inherits the transaction is called, it rolles back the transaction. The transaction in the MDB will the also be rolled back (it does not have to set RollbackOnly.

- The MDB throws an EJBException in onMessage: this will also rollback the message receipt.


Or is this not the behaviour you where looking for?

Remember however, if you constantly rollback the receipt of a message, JBoss will start running in a tight loop, since it will try to send the message on and on.

Basically, if you think you will never have success in receiving the message, you SHOULD receive it, otherwise bad things will happen since JBossMQ does not have a Dead Letter Queue.

//Peter

[pra]

Hi,
I have now merged the chanes into the 2.4.x tree. Either wait for the 2.4.1 relese or check out the 2.4 version (see cvs instructions on how to do that).

A nice feature with the latest 2.4.x is that JBossMQ 1.0 beta is now backported - and this is the fastes, most stable and feature rich version of JBossMQ, EVER.

//Peter