[
https://issues.apache.org/jira/browse/ARTEMIS-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17676703#comment-17676703
]
Justin Bertram commented on ARTEMIS-4128:
-----------------------------------------
Can you elaborate on or provide a specific example of a time when you didn't
get the expected result? Generally speaking the more details the better.
To be clear, messages which are scheduled or are in-delivery are not really
"in" the queue and are therefore not available for browsing. Might this account
for the discrepancy you're seeing?
It's worth noting that the [JavaDoc for
QueueBrowser|https://docs.oracle.com/javaee/7/api/javax/jms/QueueBrowser.html]
states:
bq. Messages may be arriving and expiring while the scan is done. The JMS API
does not require the content of an enumeration to be a static snapshot of queue
content. Whether these changes are visible or not depends on the JMS provider.
In other words, there will be natural variation between JMS providers in the
behavior of their QueueBrowser implementations. Simply put, the JMS API doesn't
provide a direct, reliable way to get the number of messages in a queue.
ActiveMQ "Classic" has a limitation whereby you can only browse the messages
which are in the broker's memory (i.e. not paged to disk) so that if the queue
is very large you won't get an accurate count.
I can't speak to any related limitations for IBM MQ as I've not used it.
Looking around the internet in places like Stack Overflow and other support
forums you'll find the main recommendation is actually to use the provider
specific mechanism. This recommendation is also made for ActiveMQ "Classic" on
the [users mailing
list|https://lists.apache.org/thread/sof15y7zg66nmsryghvfdvsy2p97lqyz] and [on
Stack
Overflow|https://stackoverflow.com/questions/43291678/how-to-get-number-of-pending-message-in-a-jms-queue].
> Enable JMS-Native Queue MessageCounter
> --------------------------------------
>
> Key: ARTEMIS-4128
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4128
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: JMS
> Affects Versions: 2.19.1, 2.26.0
> Reporter: Jose Plascencia
> Priority: Minor
>
> Artemis Version: 2.26.0
> Artemis JMS Client Jar Versions: 2.19.1
> When using Spring's JMSTemplate to run a generic “browse” call using any
> ConnectionFactory compliant object to get the number of messages on a queue,
> the response does not actually provide all messages on the queue.
> Specific Use Case:
> On a loop, gather the number of messages on a queue to enable some action to
> occur once the queue is identified as being empty. This implementation occurs
> by using Spring's JMSTemplate and loading in a valid ConnectionFactory object
> and then calling "jms.browse(queueName)”, overriding the “doInJms” function
> and enumerating over the QueueBrowser object to get the size of the
> Enumartion list.
>
> When using other JMS-based Broker solutions such as IBM MQ v8.x, v9.X, and
> ActiveMQ 5.X (Classic) (and its associated JMS client JARs), the size of the
> queue is correctly identified by using "browse" on a loop and correctly
> identifies when it becomes empty and no longer has messages.
> However, when using Artemis (and its set of JMS client JARs), the “browse”
> functionality returns inaccurate counts and will often claim the queue is
> empty even though it can be physically seen that there are still messages on
> the queue.
> I believe this behavior occurs because the “browse” interface is not
> accounting for messages in other states such as pending, scheduled, or
> in-delivery (in buffer). I have discovered that QueueControl object’s
> “getMessageCount()” correctly accounts for those other states and provides an
> accurate count.
> Between IBM MQ and ActiveMQ Classic, the “browse” interface responds as you’d
> expect, but Artemis is not – Artemis should provide the correct underlying
> implementation for the “browse” interface and respond with a more accurate
> message count as most users would expect to be able to retrieve. There is
> otherwise no JMS native method to retrieve this method and users are forced
> to resort to ActiveMQ-specific implementation and classes
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
