0 Replies Latest reply on Jul 18, 2013 6:29 AM by Ivan Scarcia

    Redelivery policy does not work properly

    Ivan Scarcia Newbie

      Hi to everybody,

      I'm Ivan and I work for an IT company in healthcare.

       

      We are experiencing a problem using hornetQ: sometimes, when a message causes a transaction rollback due to a system exception, the redelivery policy seems not working properly and the message is stuck in the queue.

       

      Our redelivery policy is to retry a message delivery every 10secs for 3 times, and then move it in DLQ.

       

      Here the configuration taken from hornetq-configuration.xml:

       

           <address-setting match="#">

                 <dead-letter-address>jms.queue.DLQ</dead-letter-address>

                 <expiry-address>jms.queue.ExpiryQueue</expiry-address>

                 <redelivery-delay>10000</redelivery-delay>

                 <max-delivery-attempts>3</max-delivery-attempts>

                 <max-size-bytes>52428800</max-size-bytes>

                 <page-size-bytes>10485760</page-size-bytes>

                 <message-counter-history-day-limit>10</message-counter-history-day-limit>

                 <address-full-policy>PAGE</address-full-policy>

              </address-setting>

       

       

      Following is what sometimes happens:

      - a RuntimeException (this is to say, a system exception) is thrown while message processing;

      - the transaction rollbacks;

      - the message is stuck in the queue and it is not redelivered;

       

      The message processing is made by a stateless EJB called from a MDB using reflection, here is the code of the MDB:

       

      @Override

                public void onMessage(Message message)

                {

                            try {

                           mdb.invoke(target, message, connectionFactory);

                  }

                 catch (Throwable th) {

                 context.setRollbackOnly();

                 mdb.logError(th, "error on DocumentMessageReceiverImpl_ProcessDocumentMessageMDB");

                  }

                }

       

      Our configuration is:

       

      OS:

      linux

       

      Kernel:

      2.6.32-100.26.2.el5

       

      jboss:

      6.0.0 final

       

      JDK:

      jdk1.6.0_31

       

      hornetQ:

      2.1.2.Final

       

      Do you know if it is a known bug? If so, it has been fixed in a subsequent version?

      Since we can't upgrade the version, do you know if there is a work around for hornetQ 2.1.2?

       

      Let me know if you need more infos.

       

      Thank to all!!

       

      Bye,

      Ivan