Inconsistencies using browseMessages() in JMX on a queue

• Key: AMQ-2295
• Type: Bug
• Status: Open
• Priority: Major
• Assignee: Unassigned
• Reporter: David Schlenk
• Component/s: JMX
• Affects Version/s: 5.2.0

Description

I'm trying to write a utility to monitor our JMS queues using JMX. I'm having a hard time getting all of the messages currently in queue to show up when I call the browseMessages operation. It seems to randomly stop keeping track of how many messages are actually in the queue after a period of time when no consumers are active on the queue. Once a consumer connects and starts consuming messages then the browse function seems to work OK again. I'm using this configuration for my persistence:
<persistenceAdapter>
<amqPersistenceAdapter syncOnWrite="false" directory="${activemq.base}/data" maxFileLength="20 mb"/>
</persistenceAdapter>

Messages come in via stomp (<transportConnector name="stomp+ssl" uri="stomp+ssl://localhost:1940) and are consumed via http (<transportConnector name="ihttp" uri="http://localhost:61618"/>).

Comments

[David Schlenk]

I seem to be able to reproduce the problem by connecting and consuming all messages and then disconnecting, then let a few messages pile up, then run browseMessages and it will return the proper list at this point. Once more messages come in, however, the browseMessages operation will continue to get only the list of messages it retrieved during the previous run. This behavior continues until a consumer connects and begins consuming messages.

[David Schlenk]

Correction: you do not need to consume any messages in order for the correctly sized list to be returned by the browseMessages operation again. As a work around I tried connecting and setting up a consumer but then immediately closing that consumer and that seems to be enough of a wake up call to fix the functionality of operation. Kind of ineffecient and bad design tho...

[David Schlenk]

ok i was wrong again: connecting to the queue but not consuming messages does not reliably work around this issue. I'm not excited about the fact that this operation is basically useless.