| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Stand alone JMS application high CPU usage |
« View previous topic :: View next topic » |
| Author |
Message
|
| kevinQ |
 Posted: Wed Apr 09, 2008 12:28 pm Post subject: Stand alone JMS application high CPU usage |
 |
|
Novice
Joined: 09 Apr 2008
Posts: 21
|
Hi, Guys and Gals,
This is my first JMS application. It stays in a loop to wait for messages to appear on a queue.
while(message == null){
if(logger.isDebugEnabled())
logger.debug("waiting for messaage");
message = queueReceiver.receive(600000);
if(logger.isDebugEnabled()){
if(message == null)
logger.debug("null message received");
else
logger.debug("received non-null message");
}
}
I found that after receiving and processing a fairly big message (29MB), the JVM's CPU usage stays around 10%, even when the program is just waiting for a message. The footprint of the JVM would grow to about 700MB and then drop back to 150MB, and then grow to 700MB and drop back ... all within the 10 minutes (600000 milliseconds) while the application was doing nothing but waiting for a message.
In my old C/C++ world, the CPU usage of the application normall drops to around 0% while waiting for a message, and the footprint is stable as long as there is no memory leak in the program.
I am on WMQ V6.0.2.2 on HP-UX 11.11, and JMS the application is running on the same machine where the QMGR runs.
Any advice??
Thanks in advance!! |
|
| Back to top |
|
 |
| smartz |
| Posted: Thu Apr 17, 2008 2:14 am Post subject: |
|
|
Newbie
Joined: 18 Feb 2008
Posts: 9
|
Hi,
sorry in advance if this does not help towards resolving your problem, but if your application is Java and you need to read messages as they come from queues, why don't you write a MessageDrivenBean (MDB)?
That way your java code would be triggered by the inflow of messages.
You need an application container (WebSphereAS or JBoss) to make that possible.
Hope this can be an idea. No idea of why a loop should behave in that way. I would start by checking that all resources used are closed correctly in try/finally statements. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu Apr 17, 2008 4:15 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
Just some "random" thoughts...
You mention nothing of how you have set the queueReceiver object before receing a message.
I have experienced high CPU if you are using message selectors because they are not supported in MQ (yet - see MQv7) and as a result the JMS implementation provided by IBM must go and browse the queue for newly arrived messages and parse each one to see if the selector matches and then do a "proper" get.
Additionally, I am not sure whether such an extended wait interval would be broken down into multiple shorter intervals within the JMS layer - effectively implementing an internal loop not dissimilar to your own example. I would advise checking IBM's Java manual for details on how JMS selectors/wait intervals are handled (if documented at all).
There's also the auto/manual acknowledgement of message receipt in JMS terms which, if you're not doing may affect what JMS does internally (i.e. not getting blocked on an MQGET call with a 10 minute wait interval).
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| kevinQ |
| Posted: Thu Apr 17, 2008 5:54 am Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 21
|
| smartz wrote: |
Hi,
sorry in advance if this does not help towards resolving your problem, but if your application is Java and you need to read messages as they come from queues, why don't you write a MessageDrivenBean (MDB)?
|
This app is on the legacy side, where there is no application server. It is a bridge between the application server and the legacy app.
I think any input in this forum is always appreciated, because that means at least you were looking at my question and wanted to help. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Apr 17, 2008 5:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Java does a lot of dynamic memory allocation, and a lot of garbage collection of that dynamic memory allocation... so this will likely explain a lot of what you're seeing.
It's only in one part of the JVM runtime that the java code is blocked on the MQGET call - the rest of the JVM is doing other things. This is particularly true with JMS - see scottj2512's comments.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinQ |
| Posted: Thu Apr 17, 2008 6:03 am Post subject: |
|
|
Novice
Joined: 09 Apr 2008
Posts: 21
|
I am reading the documents these couple of days. Since our expected max message size is around 2MB, I wasn't too worried about it. This only happens when I test with a real big message, like over 20MB. Otherwise, I'd have opened a PMR with IBM already 
I am not using the message selector in this app. It simply gets all the messages on the queue, process them and passes them onto the legacy app. The application server side they are using the selector in some cases, and I was wondering about exactly the samething -- does MQ need to browse all the messages on the queue and would that cause any overhead when the queue depth gets high.
Thanks for the auto acknowledgement hint. I think that's definitely something worth checking. I will pay some attention in that area.
| scottj2512 wrote: |
Just some "random" thoughts...
You mention nothing of how you have set the queueReceiver object before receing a message.
I have experienced high CPU if you are using message selectors because they are not supported in MQ (yet - see MQv7) and as a result the JMS implementation provided by IBM must go and browse the queue for newly arrived messages and parse each one to see if the selector matches and then do a "proper" get.
Additionally, I am not sure whether such an extended wait interval would be broken down into multiple shorter intervals within the JMS layer - effectively implementing an internal loop not dissimilar to your own example. I would advise checking IBM's Java manual for details on how JMS selectors/wait intervals are handled (if documented at all).
There's also the auto/manual acknowledgement of message receipt in JMS terms which, if you're not doing may affect what JMS does internally (i.e. not getting blocked on an MQGET call with a 10 minute wait interval). |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 17, 2008 5:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kevinQ wrote: |
| The application server side they are using the selector in some cases, and I was wondering about exactly about the same thing -- does MQ need to browse all the messages on the queue and would that cause any overhead when the queue depth gets high. |
Search some of the posts here:
The only efficient use of a selector, (up to and including V 6.0), is in provider mode (ID:hexvalues) and on some very specific fields (msgid, correlid, groupid) etc...
Any other use needs to browse each message and will slow down considerably the process. You'd be better off to use a distribution pattern than a selection pattern... (read all messages without selection and distribute to target queues according to selection)...
Enjoy  
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
