[
https://issues.apache.org/jira/browse/ARTEMIS-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jose Plascencia closed ARTEMIS-4128.
------------------------------------
Resolution: Not A Problem
The Browse functionality is providing the expected functionality. The JMS API
provides guidance and freedom for interpretation regarding message states while
in-process. The "Classic" implementation differs from the Artemis
implementation, but is largely more correct. A JMS browser only has access to
the messages actually available on the queue. Because messages are loaded in to
a buffer to a consumer, they are not actually "available" and therefore not
browsable.
> 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)
