Operations at my company uses this information, probably because that's what's available.
What we care about is for the last N minutes, the general trends: How many messages were added, how many were removed. I don't know if they care about historical data, though it is interesting to see how many messages were processed yesterday at 10PM versus two days ago at 10PM.
Now, what may be a good replacement or addition would be number of messages in/second versus number out/second. Also, queue wait times might be good too. (Subtract now - minus the JMS message timestamp, now for the last N messages, what was the average value?)
Generally, I don't think JBoss should keep around historical data. There should be a separate object that polls/receives statistics every hour or day and provides a way to export/present it to the user.
Currently, we use "Cacti" to graph (http://www.cacti.net/), which polls statistics and saves them to disk. If you're really interested in data like this over time, you need a way to persist it.
Thanks for the input, genman. I did see your reply earlier but things have been a little busy here, but I at least wanted to let you know that your input is appreciated.
There appears to be a JIRA issue related to this topic:
For now, our plans are to leave the implementation as is (using the html results returned by MessageCounter.listMessageCounterHistory() method), and once JBMESSAGING-122 is resolved, we will update the admin console to display that data, and thus close issue JBADMCON-119.