3 Replies Latest reply on Nov 3, 2005 8:14 AM by Adrian Brock

    Messages redelivered even if acked

    Andreas Rehn Newbie

      Hi,

      I'm struggling with setting up my jboss 3.2.3 and my MDBs to handle redelivery of messages in a good way but I need some help. I have the following code structure

      public void onMessage(Message m) {
       try {
       // do someting the might fail
       } catch (HandledException he) {
       // Exception due to something that migt recover, typically
       // DB dead-locks due to high load
       log.info("Handled exception, rollback transaction")
       context.setRollbackOnly();
       } catch (IgnoredException ie) {
       // Exception should be ingored, no point of redeliver message
       log.errror("Ignored Error");
       }
      }
      


      The "HandledException" works fine, the transaktion is rolled back and the message is redelivered as expected. But when I try with an exception that should be ignored, i.e. message should be acked, it doesn't work like I excpected. The code executes fine but the message is still redelivered to MDB until it is exhauseted and put on DLQ.

      Can anyone explain to me why this is happening?

      Oh yes, if I execute the code without provoking any exception at all it works just fine, the message is acked and not redelivered.

      I'm using Auto-Acknowledge but I'v tried client-ack with not success, I've also tried m.acknowledge() in the IgnoreException block but that doesn't do any difference at all. What am I missing?

      I'd appreciate all help, I'm afraid I'm stuck on this.

      Thanks

      Andreas

        • 1. Re: Messages redelivered even if acked
          jaikiran pai Master

           

          "anre42" wrote:

          but I'v tried client-ack with not success, I've also tried m.acknowledge() in the IgnoreException block but that doesn't do any difference at all.


          CLIENT_ACKNOWLEDGE is NOT meant for MDBs. Have a look at:

          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70481



          • 2. Re: Messages redelivered even if acked
            Andreas Rehn Newbie

            Thanks for the reply, I now understand more about the different ack-modes. However, my problem still remains. In order to get more to get more control of all commits and rollbacks I tried BMT instead, with the following code structure

            public void onMessage(Message m) {
             log.debug("Start onMessage()");
             try {
             log.debug("Starting transaction");
             context.getUserTransaction().begin();
             } catch (Exception e) { log.error("Failed to start transaction"); }
             try {
             // do something that might fail
             } catch (HandledException he) {
             log.info("Caught HandledExcption, rolling back transaction")
             try {
             context.getUserTransaction().rollback();
             } catch (Exception e) {
             log.error("Failed to rollback transasction " + e.toString());
             }
             return;
             } catch (IgnoredException ie) {
             log.error("Caught IgnoredException, ignoring");
             }
             log.debug("Commiting transaction");
             try {
             context.getUserTransaction().commit();
             } catch (Exception e) {
             log.error("Failed to commit transasction: " + e.toString());
             }
             log.debug("End onMessage()");
            }
            


            And again, in the normal case, i.e. no exception is thrown it works ok and the transaction is commited. But if I provoke a IgnoreException the out put would be the following:


            DEBUG Start onMessage()
            DEBUG Starting transaction
            ERROR Caught IgnoredException, ignoring
            DEBUG Commiting transaction
            ERROR Failed to commit transaction: javax.transaction.RollbackException: Already marked for rollback


            Why would the transaction already be marked for rollback in this case? I'm thinking there might be some transaction timeout? In my case it's a quite long transaction, +1 min.

            Does anyone have any idea on what might be going on here?

            Tnx

            /Andreas