Yes, this is very annoying in some situations where you depend onto this numbers. How hard / expensive (performance wise) would it be to add an configuration flag so the numbers are actually fetched from the message store instead of 'just' being the difference of (messages sent)-(messages consumed)? I think with a JDBC based persistence (no journal) this should be doable with minimal costs. Journals and Kaha stores could darken the picture, but I've no insight there.
We'll need to do some more monitoring of our queue in production to ensure that all the messages (in our case business events such as "Mr. X is now married to Ms. Y") are dispatched to and consumed by the various systems connected to our ActiveMQ-Message Bus. So until we're given an option to let activemq show 'effective' queue length the monitoring is kinda tricky. I don't really want to explain to the customer how it comes that the 'marriage-queue' has -20 messages in it.. sounds like that stupid joke where 5 people have to board the bus in order for the bus to become empty. Mario On 8/7/07, Tom Samplonius <[EMAIL PROTECTED]> wrote: > > ----- "eta" <[EMAIL PROTECTED]> wrote: > ... > > I decided to start restart both brokers & all clients. After doing > > so, I'm > > now looking at my QueueSize in broker #1 and it's showing -1000 > > messages! > ... > > This sounds like a known bug in ActiveMQ: ActiveMQ is unable to determine > the number of messages in the persistence store upon startup, so all counters > start at zero. If you had a 1000 messages in the store upon startup, and > then consumed them, it is "normal" for ActiveMQ to say the queue now has > -1000 messages in it. > > > > Tom >
