Hi Tim, Thanks for your reply.
It doesn't appear to be a statistics issue. We see same number of records in the database too. Once it hits certain numbers (3 million in our case), things start to slow down and affect performance badly. The workaround that we have in place is to cleanup the DB once it hits around 2 million. We were on AMQ version 5.15.10. Came across this issue https://issues.apache.org/jira/browse/AMQ-7425 which seemed similar to what we experience. So we tried upgrading to 5.16.3 with no luck still. Regards, Bala On 2021/10/01 12:29:08, Tim Bain <tb...@alumni.duke.edu> wrote: > The fact that pending messages > enqueued messages looks suspicious, so my > expectation is that this will turn out to be a bug in the statistics code. > But the information I requested may help us to confirm that. > > Tim > > On Fri, Oct 1, 2021, 6:23 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > > Hi, > > > > enqueued and dequeued only increase. > > > > The main indicator to check is the pending. > > > > If pending count is increasing, it means that the queue size grow > > infinitely. enqueued is the number of produced messages (not necessary > > still in the queue). So, which value are you referencing ? > > BrowsingMessages can "lock" the messages, blocking the consumers > > (depending the way you do it). > > > > Regards > > JB > > > > On 29/09/2021 09:23, Balamurugan Seenivasan 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. > > > > > >
