6 Replies Latest reply on Aug 24, 2001 6:22 AM by Peter Antman

    messagebean can't call setRollbackOnly 2.4.0BETA

    Jon Rosenberger Newbie

      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.

        • 1. Re: messagebean can't call setRollbackOnly 2.4.0BETA
          Peter Antman Expert

          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

          • 2. Re: messagebean can't call setRollbackOnly 2.4.0BETA
            Jon Rosenberger Newbie

            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>

            • 3. Re: messagebean can't call setRollbackOnly 2.4.0BETA
              Peter Antman Expert

              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

              • 4. Re: messagebean can't call setRollbackOnly 2.4.0BETA
                Jon Rosenberger Newbie

                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?

                • 5. Re: messagebean can't call setRollbackOnly 2.4.0BETA
                  Peter Antman Expert

                  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

                  • 6. Re: messagebean can't call setRollbackOnly 2.4.0BETA
                    Peter Antman Expert

                    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