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
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?
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.
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..
If you can provide step-by-step instructions to replicate, someone can take a look.