Misleading MessageCount on Topic Subscriptions ?

[tpaterson0512]

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 :

5000

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

[timfox]

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

[tpaterson0512]

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?

[timfox]

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.

[tpaterson0512]

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..

[timfox]

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