[
https://issues.apache.org/jira/browse/ARTEMIS-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17677153#comment-17677153
]
Justin Bertram commented on ARTEMIS-4128:
-----------------------------------------
The behavior you're describing is the expected behavior in ActiveMQ Artemis at
this point. In Artemis a browser sees the same messages that a normal consumer
would see. Any message which is in-delivery to one consumer is not available to
any other consumer and therefore is not available to any browser as well. This
behavior simplifies the code-base since consumers and browsers share the same
implementation almost completely, and the behavior is more consistent and
intuitive for users (i.e. since you don't see messages with a browser that you
won't see with a consumer).
You assert that the "correct" behavior is for a browser to enumerate the
messages that are in-delivery. However, the JMS specification isn't clear on
this so it's really up to the JMS providers to decide.
Consider a scenario opposite to the one you described where an application uses
a browser to see that there are 300 messages on the queue but when the
application then creates a consumer to receive those messages it actually
receives nothing because those 300 messages are in-delivery to another
consumer. That seems problematic to me.
In any event, the default semantics can't just be changed. Anybody who's used
ActiveMQ Artemis in the last 7 years may be relying on the existing semantics.
To implement this properly it would have to be configurable (i.e. more
complex). At this point, I'm not inclined to make such a change as it's not
clear the effort would be worth it (given that you're the first to complain
about it). It's also not clear to me that the behavior of "Classic" is
objectively better.
Clearly consistency between "Classic" and Artemis is important, but as [the
website|https://activemq.apache.org/activemq-artemis-roadmap] states, "Artemis
is not meant to be a 100% complete reimplementation of ActiveMQ 'Classic'.
Features should only be reimplimented where it makes good sense." At this point
I'm _not_ sure it makes good sense to reimplement this feature.
If you wish to approximate the behavior of the "Classic" broker I recommend
disabling message buffering on your clients (i.e. {{consumerWindowSize=0}}).
This will, of course, reduce the performance of your consumers relatively
speaking, but that may not actually make a statistically significant impact to
your application.
> 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)
