5 Replies Latest reply on May 24, 2010 11:34 AM by Tim Fox

    Misleading MessageCount on Topic Subscriptions ?

    Terry Paterson Newbie

      We have noticed that when looking at the MessageCount via the JMX console,

      that is sometimes seems incorrect ?


      for example :


      We have one subscription showing :


      MessageCount = 5000,

      DeliveryingCount = 5000,

      ConsumerCount = 1,

      MessagesAdded = 26,958


      The messages should be consumed by a JMS Bridge on another machine, across a WAN,

      however - we monitored these stats for a while - and they did not move.


      We then added 75 additional messages to the Topic,

      and saw that MessageCount, DeliveringCount, and MessagesAdded all increased by 75,

      and the extra 75 messages were then consumed,

      after which the MessagesAdded, DeliveringCount then returned to 5000.



      if we invoke listMessagesAsJSON() - we see :




      which seems to suggest no messages ?


      but if we invoke countMessages() - we see :






      the messages are durable,

      there is no specific priority set,

      we have paging turned on -- although HornetQ does not currently appear to be paging,

      (no data/hornetq/paging directory).


      and the same syptoms show on more than one subscription,

      for more than one Topic.


      also - this build came from TRUNK

        • 1. Re: Misleading MessageCount on Topic Subscriptions ?
          Tim Fox Master

          It's hard to tell without seeing any config, but at first look I don't see anything inconsistent.


          MessageCount = messages in queue + delivering count + scheduled count


          listMessagesAsJSON will only list the messages in the queue


          whereas messagecount will include the delivering count too

          • 2. Re: Misleading MessageCount on Topic Subscriptions ?
            Terry Paterson Newbie

            As far as the number in the MessageCount field, what you have said  makes sense.

            We have 5000 in the deliveringCount and 0 in the scheduledCount which gives us the 5000 in the MessageCount.


            The  problem that we think we have is that the deliveringCount and messageCount never get any lower than 5000.


            When we add any additional messages, we can see these  being consumed and the figure will return back down to 5000, but stops  there.


            There are no scheduled messages and the priority of the messages is the same (default).


            Is there any reason why this may happen?

            • 3. Re: Misleading MessageCount on Topic Subscriptions ?
              Tim Fox Master

              The bridge is just a consumer that consumes messages from the source queue and forwards them across the network to the target.


              Messages will be in "delivering" state until they have acknowledged from the target.


              Acknowledging is done in batches of confirmation-window-size (see user manual)


              Probably the confirmation-window-size you are using corresponds to about 5000 of your messages.

              • 4. Re: Misleading MessageCount on Topic Subscriptions ?
                Terry Paterson Newbie

                I think we are maybe getting our wires crossed a little bit..


                from what we see -- it almost seems like these 5000 messages are phantom ?


                in that -- they never seem to get delivered / consumed..


                its like a counter has been increased at some point, but never correspondingly decreased,

                and so we now always have a 5,000 offset ?



                we can add as many messages to the topic as we like,


                and these additional messages will be consumed/delivered..


                but the orignal 5,000 number always remains (many hours later)..




                I can see that something like this might happen - if those messages were scheduled to be delivered at a later time / date,

                or if the extra messages we are sending are of a higher priority than those already being delivered (if they actually exist)..


                but - we are not using message priority or scheduling..



                FYI -- We are using the JMS Bridge in a "pull" type scenario,

                e.g. the JMS Bridge is pulling messages from the remote topic subscription,

                and copying into a local queue - although I'm guessing that this is insignificant.



                the same thing is happening on other subscriptions, and other topics too,

                sometimes 2000 messages, sometimes 3000 messages, etc..

                • 5. Re: Misleading MessageCount on Topic Subscriptions ?
                  Tim Fox Master

                  If you can provide step-by-step instructions to replicate, someone can take a look.