[ActiveMQ-Artemis] Questionable behavior for message counting using QueueBrowser browse

["Plascencia, Jose [USA]" <Pl...@bah.com.INVALID>]

Artemis Version: 2.26.0
Artemis JMS Client Jar Versions: 2.19.1

I attempted to use Springs JMSTemplate object to run a generic "browse" call using any ConnectionFactory compliant object and get the number of messages on a queue. This occurred by calling the "jms.browse(queuName)", overriding the "doInJms" function and enumerating over the QueueBrowser object to get the size of the Enumartion list.
I am attempting to do this on a queue actively being consumed from to identify when it becomes empty.

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

My question is - between IBM MQ and ActiveMQ Classic, the "browse" interface responds as you'd expect, but Artemis is not - is there any reason that Artemis should not provide the correct underlying implementation for the "browse" interface and respond with a more accurate messageCount as most users would expect to be able to retrieve?

Thanks,
Jose

Re: [ActiveMQ-Artemis] Questionable behavior for message counting using QueueBrowser browse

[Justin Bertram <jb...@apache.org>]

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.

For what it's worth, messages which are scheduled or are in-delivery will
not be sent to queue browsers because they are not really "in" the queue
and are therefore not available for browsing.

Lastly, the JavaDoc for QueueBrowser [1] notes:

  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.


Justin

[1] https://docs.oracle.com/javaee/7/api/javax/jms/QueueBrowser.html

On Fri, Jan 13, 2023 at 8:53 AM Plascencia, Jose [USA]
<Pl...@bah.com.invalid> wrote:

> Artemis Version: 2.26.0
> Artemis JMS Client Jar Versions: 2.19.1
>
> I attempted to use Springs JMSTemplate object to run a generic "browse"
> call using any ConnectionFactory compliant object and get the number of
> messages on a queue. This occurred by calling the "jms.browse(queuName)",
> overriding the "doInJms" function and enumerating over the QueueBrowser
> object to get the size of the Enumartion list.
> I am attempting to do this on a queue actively being consumed from to
> identify when it becomes empty.
>
> When using 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
> 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.
>
> My question is - between IBM MQ and ActiveMQ Classic, the "browse"
> interface responds as you'd expect, but Artemis is not - is there any
> reason that Artemis should not provide the correct underlying
> implementation for the "browse" interface and respond with a more accurate
> messageCount as most users would expect to be able to retrieve?
>
> Thanks,
> Jose
>