I'm going to disable the MessageCounter stuff in 4.0.4
if the original author doesn't maintain it.
The correct fix is to implement the history by extending the MessageStatistics.
(AKA a proper job).
I assume you are not volunteering to maintain this?
You assume correctly.
I will organize for the Admin Console to use the MessageStatistics attribute in place of listMessageCounter() and get a JIRA issue raised to extend MessageStatistics as described.
Let me see if I understand correctly. It appears that MessageStatistics is a serializable snapshot of the current state of the data found in MessageCounter. I base this statement on the fact that I could find only one location where a MessageStatistics instance is created, and that is in MessageCounter.getMessageStatistics(). (I looked in both jboss-head and jboss-4.0.x in CVS.)
What confuses me is the statement
I'm going to disable the MessageCounter stuff in 4.0.4I'm note sure how MessageCounter could be disabled if it actually maintains the statistics. Adrian, could you perhaps clarify your inent?
The reason I am asking, is that I was going to attempt to add the message counter history functionality to MessageStatistics. At this time what I envision is adding another property to MessageStatistics and populating that property in the MessageCounter.getMessageStatistics() method.
Your thoughts on this are appreciated.
You are referring to this?
The MessageCounter was added by a contributor in the 3.2.x days.
It's had a number of problem that I have had to fix.
If the original contributor doesn't maintain their "optional feature" it gets removed
or disabled by default when it causes problems and I loose patience.
This is called orphaned code.
The two biggest problems with the MessageCounter are:
1) It can be a performance bottleneck
2) The api to access the statistics is broken
2a) It is not serializable
2b) Most of useful data is accessed by some custom (and currently broken) html processing.
2c) All statistics should be exposed via the JSR77 model as javabeans
MessageStatistics is the start of an attempt by me to solve these problems,
but it is not high on priority list to complete.
I'm note sure how MessageCounter could be disabled if it actually maintains the statistics.
Simply by setting the default config to not collect the stats with a warning
that says "enable at your own risk".
And a few tests of this feature would greatly improve my motivation to maintain it! :-)
Yes, JIRA issue JBAS-1908 is one of the issues I am referencing, but also
I wholly agree with your your statement that MessageCounter is a performance bottleneck. Just looking at the code used to maintain the counter history (e.g., UpdateHistory()) had me shaking my head. (On another project I had code that did date manipulation in a multi-threaded environment and when I ran the code I noticed that the processors were using up a lot if system time as opposed to user time. I changed the code to use non-date data and noticed a huge performance improvement.) I was even planning on evaluating the performance overhead of gathering the message counter history. We already have a question on the admin console forum to see if anyone really wants this data (see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=71908). If no-one wants it, why bother gathering it? But then, providing an option whereby statistics gathering can be turned on and off makes sense. Something like this should be settable from the admin console.
My question on turning off the message counters was not really about the machanics of doing it, but rather a question of how MessageStatistics would go about providing the statistics if MessageCounter was removed. I assume that quite a bit of implementation would be involved to get MessageStatistics to replace MessageCounter. And I can see where such a thing would be low on the priority list.
If I may butt in.
I've been interested in adding rate statistics, i.e. "messages per second". Currently, I maintain a rate counter internally in my MDB.
See this discussion.