| Author |
Message
|
| KenCoe |
 Posted: Thu Jan 20, 2005 8:01 am Post subject: High message Counts on JAVA.CLIENT.CHANNEL using JMS |
 |
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
Hello all,
I have a question about how MQ JMS message receivers get their messages from the Queue Manager; here's the run-down of what we've observed:
--MQ JMS Client is listening for messages using a JMSCorrelationID...the MQ Queue Manager is running on Z/OS.
--if the non-expired message count on the queue is, say 100, and we observe the JAVA.CLIENT.CHANNEL total message counter on the Z/OS system, we observer the message counts for our client incrementing by 100 ever few seconds. Similarly, if the non-expired message count on the queue is 300, the message counts increment by 300, etc. This test assumes that NONE of the messages on the queue have the same correlationID that the client is looking for.
It appears that the client is pulling all the messages on the queue back to examine them for it's JMSCorrelationID. I would have expected the QueueManager deliver only one message (with RC=2033), if none of the messages matched the correlationID, but we're seeing message counts on the client channel increment commensurate with the queue depth. Is this right? Is there a bug? Does this make sense?
anyone?
Ken Coe
Systems Analyst
Blue Cross and Blue Shield of Alabama |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Thu Jan 20, 2005 8:03 am Post subject: Re: High message Counts on JAVA.CLIENT.CHANNEL using JMS |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| KenCoe wrote: |
| MQ JMS Client is listening for messages using a JMSCorrelationID. |
How are you doing this? Are you using a selector? What does it look like? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 20, 2005 8:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, is your queue indexed, or not?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KenCoe |
| Posted: Thu Jan 20, 2005 8:09 am Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
| jefflowrey wrote: |
| Also, is your queue indexed, or not? |
Originally it was not indexed, but we've also tried indexing by CorelId, and the behaviour was the same. |
|
| Back to top |
|
|
| KenCoe |
| Posted: Thu Jan 20, 2005 8:11 am Post subject: Re: High message Counts on JAVA.CLIENT.CHANNEL using JMS |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
| bower5932 wrote: |
| KenCoe wrote: |
| MQ JMS Client is listening for messages using a JMSCorrelationID. |
How are you doing this? Are you using a selector? What does it look like? |
Here is a code snippet:
| Code: |
try {
QueueConnectionFactory qcf = (QueueConnectionFactory) ApplicationContext.lookup("qmgr");
Queue qName = (Queue) ApplicationContext.lookup("cisClientNotifyQueue");
conn = qcf.createQueueConnection();
conn.start();
sess = conn.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
String hostName = (String) ApplicationContext.lookup("ClientNotifyId");
System.out.println("JMSCorrelationID: " + hostName);
String messageSelector = "JMSCorrelationID='" + hostName + "'";
receiver = sess.createReceiver(qName, messageSelector);
receiver.setMessageListener(this);
}
catch (JMSException jmse) {
System.err.println(jmse);
closeResources();
}
|
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 20, 2005 8:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| KenCoe wrote: |
| Originally it was not indexed, but we've also tried indexing by CorelId, and the behaviour was the same. |
Well, worth a shot.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KenCoe |
| Posted: Thu Jan 20, 2005 8:13 am Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
| I'd be curious to know if anyone else can reproduce this behaviour (if anyone has the time). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 20, 2005 12:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Please don't use a message listener with a selector on correlationID.
Typically the correlationID gets the value of the message that carried the request. The JMS implementation of message listener is really geared only towards the optimized use for an MDB that consumes all the messages from the queue.
If you need to use a listener with a selector think about alternates like a receiver with a selector.
You will see quite a performance degradation as soon as you put another listener on the queue with a different selector.
What are you really trying to achieve here ?
F.J.  |
|
| Back to top |
|
|
| KenCoe |
| Posted: Thu Jan 20, 2005 5:40 pm Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
| fjb_saper wrote: |
Please don't use a message listener with a selector on correlationID.
Typically the correlationID gets the value of the message that carried the request. The JMS implementation of message listener is really geared only towards the optimized use for an MDB that consumes all the messages from the queue.
If you need to use a listener with a selector think about alternates like a receiver with a selector.
You will see quite a performance degradation as soon as you put another listener on the queue with a different selector.
What are you really trying to achieve here ?
F.J. |
I thought that I was using a receiver with a selector (see code snippet from my previous post).
Here's what I'm trying to accomplish (and it works, but I'm noticing the aforementioned issue with messages):
Many clients (hundreds) need to pull their own messages from a common queue. To do this, the client is using a receiver with a string selector which is equal to the text "JMSCorrelationID=hostname" , where hostname is the hostname of the client. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 20, 2005 6:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You would be better off creating one queue per hostname
Then you would have one process that does nothing but take each message from the queue and move it to the correct hostname queue. This can use a MessageListener.
Basically you build a router pattern. You could even create the target host queue dynamically if it does not exist.
Each target has then a queue at his disposal wich he no longer needs to share.
Depending on whether it will suit your needs or not you could as well do a publish subscribe model. It is well suited for a router pattern.
Enjoy |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 21, 2005 5:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Actually, in this case, KenCoe may be better off using dynamic queues instead of static queues. Then his administration is simplified (for hundreds of clients!) and he still has message accountability (knows who a certain message is for, and therefore who is having problems getting messages).
Unless the messages need to be persistent.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KenCoe |
| Posted: Fri Jan 21, 2005 7:16 am Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
| jefflowrey wrote: |
Actually, in this case, KenCoe may be better off using dynamic queues instead of static queues. Then his administration is simplified (for hundreds of clients!) and he still has message accountability (knows who a certain message is for, and therefore who is having problems getting messages).
Unless the messages need to be persistent. |
The messages do not need to be persistent. Since we've not used dynamic queues in such large numbers before, I'm concerned about performance or other issues that I might not know about. Are there any special considerations I should take note of when using this many dynamic queues?
By the way, thanks to everyone for your help on this. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 21, 2005 9:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Performance with temp dyn queues has improved greatly in 5.3 compared to 5.2 of MQ. The QM keeps a pool of queues ready to use behind the scenes (GHOST queues if you poke around in the dirs). When you need a new temp q, the QM grabs one from the pool, rather than having to create one from scratch.
How many do you want to make?
As for perfomance, you should test it both ways, and see what is better. Were it not for the JMS, I would say hands down use the indexed queue for all, or maybe 10 indexed queues. But this selector thingie (scary JMS!) may prove that model slower than using temp queues.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 21, 2005 9:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| I would say hands down use the indexed queue for all, or maybe 10 indexed queues |
Except then you can't identify which app is failing by looking at queue depth, you have to read the messages in the queue. And it's a *lot* easier to program a monitoring tool to alert on queue depth than it is to program it to browse messages and alert based on contents.
Yes, this sounds like a user interface application - so the user will know if there is a problem. But that's subject to the usual caveats of the skill of the user and the skill of the developer.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| slaupster |
| Posted: Thu Jan 27, 2005 2:28 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004
Posts: 41
|
| going back to the original question, this observation is entirely correct. The QMGR does not push messages to clients, it is the clients that pull messages from the QMGR. This makes far more sense considering the performance implications of reversing this. It would be far too much work for the QMGR to determine message suitability for each and every client's various message selection criteria, so this work is devolved to the clients by sending them the headers. |
|
| Back to top |
|
|
|
|
