How are you determining the counts you referenced? I'd expect you could get them from the web console or by doing SQL queries against the database, and I'd encourage you to do both and compare the numbers.
I'm hoping you'll find that the stats from the web console (which are sourced from the JMX beans) are wrong but the database is right, since that presents a problem for monitoring but not message distribution. But knowing the symptoms will help identify where in the code we should be looking for the problem in order to fix it. Tim On Wed, Sep 29, 2021, 6:24 AM Balamurugan Seenivasan <[email protected]> wrote: > Hi, > > We notice an issue recently in production where the messages in queue size > grows disproportionate to the number of messages actually produced. > Queue size grows close to 3 million in about 3 days while the actual > messages produced are way less than the actual queue size. > > Here is one snapshot of how the queue looks like when actual messages > produced are only around 60000. > 794712 (pending) 8(consumers) 679793(enqueued) 507419(dequeued) > > We use browseMessages extensively (from around 50 threads) using selectors > like 'JMSCorrelationID LIKE <data>%'. > We notice this issue only with those queues we use browseMessages against. > Not sure if there is a link to usage of browseMessages. > > AMQ version: 5.16.3 (windows) > Persistence: > Yes (Microsoft SQL Server 2019 on Linux (Ubuntu 16.04.6 LTS) <X64>, > mssql-jdbc-9.4) > config: > <persistenceAdapter> > <jdbcPersistenceAdapter > dataDirectory="activemq-data" dataSource="#mssql-ds" > lockKeepAlivePeriod="5000"> > <adapter><transact-jdbc-adapter/></adapter> > <locker> > <lease-database-locker > lockAcquireSleepInterval="10000"/> > </locker> > </jdbcPersistenceAdapter> > </persistenceAdapter> > > Appreciate any help/pointers narrowing down the cause. >
