2 Replies Latest reply on Aug 9, 2011 8:46 PM by clebert.suconic

    invoking stopDelivery causes WARNs

    rhinmass

      I am using JBoss 6.0.0.Final and I have just upgraded to Hornetq 2.2.5.

       

      I have noticed that after upgrading when I call "stopDelivery" on my MessageDrivenBean I now get this message:

       

      14:57:55,476 WARN  [org.hornetq.core.server.impl.QueueImpl] Error on checkDLQ: java.lang.IllegalStateException: Cannot find add info 55487

              at org.hornetq.core.journal.impl.JournalImpl.appendUpdateRecord(JournalImpl.java:910) [:]

              at org.hornetq.core.persistence.impl.journal.JournalStorageManager.updateScheduledDeliveryTime(JournalStorageManager.java:546) [:]

              at org.hornetq.core.server.impl.QueueImpl.checkRedelivery(QueueImpl.java:1788) [:]

              at org.hornetq.core.server.impl.QueueImpl$RefsOperation.afterRollback(QueueImpl.java:2172) [:]

              at org.hornetq.core.transaction.impl.TransactionImpl.afterRollback(TransactionImpl.java:509) [:]

              at org.hornetq.core.transaction.impl.TransactionImpl$4.done(TransactionImpl.java:375) [:]

              at org.hornetq.core.persistence.impl.journal.OperationContextImpl.executeOnCompletion(OperationContextImpl.java:188) [:]

              at org.hornetq.core.persistence.impl.journal.JournalStorageManager.afterCompleteOperations(JournalStorageManager.java:424) [:]

              at org.hornetq.core.transaction.impl.TransactionImpl.rollback(TransactionImpl.java:363) [:]

              at org.hornetq.core.server.impl.ServerConsumerImpl.close(ServerConsumerImpl.java:340) [:]

              at org.hornetq.core.server.impl.ServerSessionImpl.closeConsumer(ServerSessionImpl.java:1038) [:]

              at org.hornetq.core.protocol.core.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:426) [:]

              at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:474) [:]

              at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:496) [:]

              at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:457) [:]

              at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:459) [:]

              at org.hornetq.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:137) [:]

              at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [:]

              at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]

              at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]

              at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]

       

      Not just once, but thousands of screenfuls (each with a different ID).  Perhaps there is one for each message on the queue, or in the client buffer.

       

      The reason I use this functionality, is that I have to stopDelivery programmatically from time-to-time to inspect the messages on the queue, and if I don't stopDelivery, I can't see the messages in the client buffer.  (Perhaps there is another way to see the messages in the clientBuffer ??)

       

      I was wondering if this is a bug, and if there is a work around.  In 2.1.2 I could call "stopDelivery" with no problem

       

      Thanks!

        • 1. Re: invoking stopDelivery causes WARNs
          clebert.suconic

          Can you open a JIRA?

           

           

          There's an issue with paged messages and scheduled Redeliveries.

           


          I'm already fixing on Branch_2_2_EAP and I will merge it into trunk and next releases soon.

           

           

          You may also disable scheduled redelivery, and this issue will go away.

           

           

          Or if you wish to change the code yourself, look at QueueImpl where updateScheduleDeliveryTime is called:

           

                      if (!reference.isPaged() && message.isDurable() && durable)

                      {

                         storageManager.updateScheduledDeliveryTime(reference);

                      }

           

           

          You can add the !reference.isPaged() what will fix it also.

           

           

          Sorry about that.

          • 2. Re: invoking stopDelivery causes WARNs
            clebert.suconic

            Actually there's a JIRA for this already:

             

            https://issues.jboss.org/browse/HORNETQ-722