Jose Plascencia created ARTEMIS-4128:
----------------------------------------
Summary: 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.26.0
Reporter: Jose Plascencia
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)
