4 Replies Latest reply on Sep 18, 2014 6:02 AM by Marc Anthony Puca

    MDB behaviour during retry

    Marc Anthony Puca Newbie

      Hi guys

       

      I have a question concerning the behaviour of HornetQ whilst retrying a delivery.

       

      This is my config under wildly (8.0.0 final)

       

      <address-setting match="#">

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

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

                              <redelivery-delay>180000</redelivery-delay>

                              <max-delivery-attempts>30</max-delivery-attempts>

                              <max-size-bytes>10485760</max-size-bytes>

                              <page-size-bytes>2097152</page-size-bytes>

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

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

      </address-setting>

       

      Lets say my MDB throws an exception, it will get put to aside and reattempted after 3mins, in the meantime are other messages processed or does the queue block?

       

      thanks

       

      Marc

        • 1. Re: MDB behaviour during retry
          Doug Grove Newbie

          Hi Marc,

           

          The JCA is responsible for message delivery and activation of the MDB.  The JCA starts JMS sessions and places a message listener on those sessions.  When a message comes in, the JCA delivers the message to the MDB.

           

          So in your scenario, messages are still delivered.

           

          I hope that helps,

           

          Doug

          • 2. Re: MDB behaviour during retry
            Marc Anthony Puca Newbie

            Hi Doug

            Thanks for the reply, looks like I may have a problem then. My MDB tries to obtain a write lock on a row then do some processing, so if there are 2 messages for the same entity one will have to wait. Now assuming I have 20 mdbs listening on the queue, yesterday I found a thousand or so messages waiting to be processed, with roughly 4 of them had been processed and couldn't acquire a lock and the rest stuck. Only after restarting the dB the queue started to be processed again. It was rather weird that the db is correlated with the mdb business process not the queue  itself. It seems that the messages that couldn't acquire a lock were stuck and stopped the rest from getting through, do you think that is possible?

             

            Thanks

            Marc

            • 3. Re: MDB behaviour during retry
              Justin Bertram Master

              It's worth getting a thread dump from the application server when it gets in this state.  It's possible that your MDB instances are hung in a database operation (or otherwise) and therefore not able to process additional messages.

               

              You could also look at the statistics for the queue when it gets into this state and check the message-count, consumer-count, and delivering-count.  If all those are > 0 but never decrease that indicates your consumers are stuck.

              • 4. Re: MDB behaviour during retry
                Marc Anthony Puca Newbie

                I have slightly changed the db settings and will monitor, it I hit the lock again will get dumps and post them.

                 

                thanks for the help guys

                 

                Marc