Hi, Thanks for your reply.
This issue exists for us even if we start out with a clean environment (with a brand new database). We even noticed this issue with KahaDB too. This is consistently reproducible for us. Regards, Bala On 2021/10/01 17:56:07, Matt Pavlovich <mattr...@gmail.com> wrote: > Hi Balamurugan- > > Is the broker restarted at any time in this sequence of events? > > > Keep in mind— > > Pending Count can be higher than Enqueue Count when the broker is restarted > and messages remained on the queue. > > a. Enqueue and Dequeue counts reset are for that broker’s uptime. > > b. Pending Count (aka queueSize) is how many messages are currently in the > store. > > -Matt Pavlovich > > > On Oct 1, 2021, at 7:29 AM, 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. > >>> > >> > >
