| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Static vs. dynamic queues |
« View previous topic :: View next topic » |
| Author |
Message
|
| smeunier |
 Posted: Fri Jun 09, 2006 6:13 am Post subject: Static vs. dynamic queues |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
In high volume Request/Reply scenarios, is is better to used static queues or dynamic queues? High volume meaning hundreds of transactions per/second.
These messages will be non-persistent, so both models apply, but I get concerned about slopy Client programming tactics leaving orphaned dynamic queues and the headache with cleaning them up. On the other hand, they are one - one with the request.
I favor a static queue implementation with reply get on correl id. This reduces overhead with dynamic queue allocation and clean up, but also implies hundreds of attachments to the reply queue. As you can tell, I also prefer a single(or few) reply queues as well.
I anticipate shallow queue depths perhaps hoving arounf 50-100 messages. The messages will have short lived expiry periods as well, as the replies are for synchrnose responses. So the expiry will ve very short.
So every get will imply cleanup by the queue manager of expired messages before retrieving its reply message. This is a normal function of the queue manager, so this should not be an issue.
I guess I'm looking for validation on using static reply queue(s) vs. dynamic. Or contradiction if the case may be.
Opinions? |
|
| Back to top |
|
 |
| JT |
| Posted: Fri Jun 09, 2006 6:33 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jun 09, 2006 7:22 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
I have to chuckle  , the scenario fits my scenario to a T, but the opionions vary, with no real direction. The overriding factor here is performance. And I think thast resides with Static definitions. It would be real easy for me to create business entity reply queues for seperation of replies.
The "fright factor"in temporary dynamic is delayed replied and terminated clients, leaving replies to go to SDLQ.
I think it comes down to 6 of one half dozen of another. But that was a real good reference.
Thanks |
|
| Back to top |
|
|
| JT |
| Posted: Fri Jun 09, 2006 7:29 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
| I think it comes down to 6 of one half dozen of another |
Then perhaps the solution that is easiest to adminster/maintain can you lead you to one over the other. |
|
| Back to top |
|
|
| tleichen |
| Posted: Fri Jun 09, 2006 7:44 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
You mentioned a message volume, but it was not clear as to how many dynamic queues you would be potentially allocating. Also, I was curious about what platform(s) are involved here. Cleaning up dynamic queues is not too difficult. We wrote and application to do it periodically on z/OS. Just my two cents. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Jun 09, 2006 9:16 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Since 5.3 WMQ reuses dynamic queues, so the overhead with creating a new dynamic queue is much less than it was previously.
_________________
MQSeries.net helps those who help themselves.. |
|
| 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
|
|
|
|
