Can't initialize MessageCounterHistoryDayLimit to zero

[jhaddad]

While analyzing the performance of my app, which runs on JBoss 3.2.5, I noticed significant cpu usage eaten up by my JMS queue's message history counter. I figured I could easily disable this by setting the MessageCounterHistoryDayLimit to zero, as show in the descriptor below. This resulted in a NullPointerException at startup caused by the jmx config service calling a setter on the underlying queue object before it was instantiated. Is there another way that I should disable this count history feature?

 <mbean code="org.jboss.mq.server.jmx.Queue"
 name="jboss.mq.destination:service=Queue,name=RequestQueue">
 <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
 <attribute name="MessageCounterHistoryDayLimit">0</attribute>
 <attribute name="InMemory">true</attribute>
 </mbean>

[jhaddad]

Somehow, the descriptor I pasted into my post got screwed up in the original post. Here it is with HTML disabled:


<depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager
0
true

[jhaddad]

Well, that didn't work either. Basically, my queue config contains an 'attribute' element with the 'name' attribute set to 'MessageCounterHistoryDayLimit' and the element body is '0'.

[adrian.brock]

Post it as a bug
http://www.jboss.org/wiki/Wiki.jsp?page=SubmitABugReport

I recently flagged in a commit message that this default cannot be changed
at deploy time, only at runtime.

It should be using BasicQueueParameters if you want to try to fix it yourself
and provide a patch.

[jhaddad]

Thanks Adrian. I will look at the code and see if I can figure out where to make the fix.

In the meantime, is there any workaround you can think of to disable this message counter history feature at deployment time?

[adrian.brock]

There are two obvious mechanisms.

1) Change the source to the default you want.

2) Install a listener on the ServiceController.
When you get a notification about a service starting, test whether it is
a Queue or Topic and invoke setAttribute() on it.

I'd also be interested to know why this statistics collection uses a lot of cpu.

Finally, this message counter stuff needs fixing in two other ways:
1) It needs to be serializable so a remote client can obtain the statistics
2) It needs to be exposed via jsr77

[adrian.brock]

A third is to extend the jboss classes

public MyQueue extends Queue
{
 protected void startService() throws Exception
 {
 super.startService();
 // change config here
 }
}

But this would not work for deployments created via the destination manager.

[jhaddad]

Adrian -

To answer your question as to why the message counter is taking up so much cpu...

I've been profiling one particular thread in my application which has popped up on my radar as a bottleneck. The thread basically receives requests via a tcp socket using a proprietary protocol. The request is wrapped up in a JMS message and enqueued to be processed by an MDBean.

After focusing on this thread with a cpu profiler, I see that approximately 8% of its cpu usage is spent invoking MessageCounter.updateHistory. Drilling down one more level, I see that the main culprits are 2% in Calendar.getTime, 2% in the constructor for GregorianCalendar, 1.5% in MessageCounter$DayCounter.updateDayCounter and .5% in MessageCounter$DayCounter.getDate().