> If the stat is right, you'd see the # bytes used in the store climbing as > well. (That stat is available in JMX, but I'm not sure it's on the web > console.)
Except I've got a couple dozen queues and they all end up writing to disk (overflowing in-memory limits). So aggregate disk (or store) usage is useless to differentiate behavior. In one particular mostly controlled setting I can see that as messages continue to come in the Store percent used has stopped climbing after the queues hit their PendingLimit. So maybe it's working as intended? I'm looking at the MBean Attributes for the queue and nothing indicates disk/store usage. I've got metrics for Dequeue, Dispatch, Enqueue, QueueSize, Memory Usage (again not useful), and Cursor usage among others. When messages roll off, does it show up in 'ExpiredCount'? That's the only one that even vaguely fits. And to answer my question, nope, it doesn't move an iota. It probably only increments when one sets a time-based expiry setting. Shouldn't I also be able to tell how many (or portion) of all enqueued messages are sitting in memory vs the backing store? I'm using the Storage cursor as opposed to VM or File. My MemoryPercentUsed and CursorPercentUsage both top out at 70 which is the default. It seems to me there are some glaring oversights to the MBeans attributes. We need a PendingLimitCount, PendingLimitTime, DiscardCount (or PendingLimitExceededCount) or just use the ExpiredCount for both time-based and count-based limits. And too a 'StorageUsageCount' which reflects the number of messages that have been spooled out to disk in excess of in-memory footprint or if counting messages is too much work, at least the Bytes consumed on disk.
