I see a very high cpu utilization (400% on 8 cpu server) when I connect consumers to OpenQ. It increase close to 100% for every consumer I add. Slowly, the consumer comes to a halt, as the producers are sending messages at a good rate too.

The stacktraces showed above indicates the broker was processing a number of closing consumer requests. Closing consumer can be CPU intensive on broker side if there are a lot of messages for the consumer or open transactions. Does your application consume messages in transactions ? If yes, if you lower the value of imq.txn.reapLimit (default 500) - a broker property to limit maximum completed transactions waiting for cleanup - do you see any difference ? Please also note that 4.3 is old. There have been a number of bugs fixed in later releases that affect consumer closing. The latest release is 4.5. You should upgrade your version of MQ.

Yes, the messages are consumed in transactions. I set imq.txn.reapLimit=200 in Start Arguments in jvm configuration.

I verified that it is being set in the log.txt file for the broker:
-Dimq.autocreate.queue=false -Dimq.autocreate.topic=false -Dimq.txn.reapLimit=250

It did not make any difference. Do I need to set this property somewhere else ?

As far as upgrading MQ is concerned, I am using glassfish 2.1. And I think MQ 4.3 is packaged with it. Can you suggest a safe way to upgrade to OpenMQ 4.5 in a running environment. I can bring down the cluster temporarily. Can I just change the jar file somwhere to use MQ4.5 ?

Here is the snippet of the consumer code :

I create Connection in @postConstruct and close it in @preDestroy, so that I don't have to do it everytime.

Broker properties can be set in GlassFish with start-args attribute (using the imqbrokerd's -vmargs option for each property) in jms-service element in domain.xml. If with substantially low imq.txn.reapLimit setting, there is no difference, then unlikely isConsumedInTransaction() is the one for the high CPU usage unless your application had a lot of in-flight transactions at the time the consumers closing.

You can upgrade GlassFish 2.1 to a GlassFish 2.1 patch that contains version of 4.4u2p2

create Connection in @postConstruct and close it in @preDestroy, so that I don't have to do it everytime.

Please see following issue on caching connection in EJB
http://java.net/jira/browse/GLASSFISH-15558

Please also note that closing and recreating consumer (closing session or connection closes its consumers) on each Session bean invocation is very costly when there are a lot of messages for the consumer.

These threads were the ones with highest cpu utilization consistently.

I tested the consumer also by creating non-tansacted session. That did not help either. So, it's not the transacted vs non-transacted sessions.

But you are right that closing the session, and recreating consumer for every invocation might be resource intensive. But not closing the session every invocation, causes JMS to run out of connection. Also, in a transacted session, the messages are sent, only if the session is committed or closed..

I cannot really upgrade glassfish version either. I was hoping there would be some article explaining how to configure glassfish v2 to use a different OpenMQ than the one that was packaged. I have installed OpenMQ 4.5, but not sure how to integrate it with glassfish, so it starts and stops with glassfish.

I will look more into how can I reduce the consumers closing and recreating at every invocation.