[
https://issues.apache.org/jira/browse/ARTEMIS-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17677385#comment-17677385
]
Jose Plascencia commented on ARTEMIS-4128:
------------------------------------------
Thank you for the clarity.
I agree with your statements and agree that a change to this JMS API
implementation is responding with the correct count given the underlying
concepts.
I agree any change here would be counterproductive and just introduce problems
to legacy users.
Consider this OBE/Resolved/Closed
> 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)
