| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| High message Counts on JAVA.CLIENT.CHANNEL using JMS |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Thu Jan 27, 2005 2:58 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If it's just the message headers being retrieved then it's not quite so bad for network performance!
I always thought that MQI calls were simply remoted by the client to the queue manager and would have expected the message selection to happen on the queue manager.
Is your explanation true for all MQI clients? |
|
| Back to top |
|
 |
| slaupster |
| Posted: Thu Jan 27, 2005 3:12 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004
Posts: 41
|
yeah it is true for all MQI clients and yes the network is not as badly hit as if it were the whole message! In fact the headers are naturally pretty small as you know so it is only a small amount of data even for large numbers of messages.
If you consider the number of clients QMGRs can typically have and the matching engine ticks required for message selection (particularly JMS) then you can appreciate the reasoning. Certainly, remoting the MQI call from the client would place an immediate cap on the number of clients a QMGR could service, with wild swings depending on the number of messages on the queues. |
|
| Back to top |
|
|
| KenCoe |
| Posted: Thu Jan 27, 2005 6:08 am Post subject: |
|
|
Newbie
Joined: 20 Jan 2005
Posts: 7
|
| slaupster wrote: |
| 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. |
Given the discussion so far, I'd appreciate a weigh-in from the group on whether dynamic queues are a better idea in this situation. Thanks in advance for your help on this. |
|
| Back to top |
|
|
| slaupster |
| Posted: Thu Jan 27, 2005 7:23 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2004
Posts: 41
|
I would say that jefflowrey is certainly right about the administration aspect - much simpler than creating 100s of static queues, though you must be sure you don't mind if MQ loses a message if there is a problem, and naturally you cannot run transactions that involve using these queues. You will be able to ID the queues from the temporaryModel queue name set on the MQQCF.
There should be no significant impact on performance using dynamic queues. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
