| Author |
Message
|
| mq_rookie |
 Posted: Thu Oct 25, 2007 11:23 am Post subject: Writing to Multiple Queues |
 |
|
Newbie
Joined: 25 Oct 2007
Posts: 4
|
Hi,
Here is my problem. I have around 2000 queues under a single Queue Manager. Most of the time my application may have to write upto over 1000 queues. I am not worried about the reply message, just need to write it to the queues.
I read in the MQ tutorials that each thread need to make a connection to the Queue manger before opening a queue. Having 1000 connection in a single process does not seems a good idea.
Any thoughts in this regard? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 25, 2007 11:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
One MQCONN
Lots of MQOPENS, or better yet MQPUT1
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Oct 25, 2007 12:03 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| 1000's of queues? This sounds like it might be a publish/subscribe type of application? |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Oct 25, 2007 1:38 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 25, 2007 2:17 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I suppose it doesn't matter if you loop over an MQPUT1 and a single return code, or loop over a nested list of return codes.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mq_rookie |
| Posted: Thu Oct 25, 2007 3:56 pm Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 4
|
The data to be written to different queus are different. Si distribution list may not work.
I didn't get what you meant by
"One MQCONN
Lots of MQOPENS, or better yet MQPUT1"
Can we use one MQCONN and then use the same handle to connect to each Queues.
Can we use the same connection handle to write to the queues in different threads?
Thanks in Advance.. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 25, 2007 4:17 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MQCONN
MQOPEN Q1
MQOPEN Q2
.
.
MQOPEN Q1000
Do While you have work to do
MQPUT to Q1
.
.
MQPUT to Q 1000
End Do
MQCLOSE Q1
.
.
MQCLOSE 1000
MQDISC
If you are only going to put 1 message to each q and the end, use 1000 MQPUT1s instead of 1000 MQOPENs, then 1000 MQPUTs and then 1000 MQCLOSEs.
This sounds like an app that should be maybe using Pub Sub.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Oct 25, 2007 4:31 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jefflowrey wrote: |
| I suppose it doesn't matter if you loop over an MQPUT1 and a single return code, or loop over a nested list of return codes. |
The requirements might state something about speed of execution and CPU load. Both of these measures will be different in the distribution list / MQPUT1 cases. Given that the distribution list example involves many fewer API calls and thread context switches from app to qmgr, I would expect the dist list scheme to win in these performance measures. However the original poster says the data is different for each put. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Oct 25, 2007 4:34 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mq_rookie wrote: |
| The data to be written to different queus are different. Si distribution list may not work. |
Peter has a good point that this sounds more like pub/sub than normal queueing.
Just let me ask directly: does the putting app really have something different to say to each of the 1000 getters?
Maybe we could help slightly better if we knew a little about the requirements why 1000 getters have to have different messages.
(But if this is sensitive information, then don't share it...) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 25, 2007 7:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Imagine an accounting application with a central office and 1000 stores.
Now depending on how the processes are written I can easily imagine the need for an app to behave like mq_rookie mentioned...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mq_rookie |
| Posted: Fri Oct 26, 2007 8:13 am Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 4
|
| fjb_saper wrote: |
Imagine an accounting application with a central office and 1000 stores.
Now depending on how the processes are written I can easily imagine the need for an app to behave like mq_rookie mentioned...
Enjoy |
| fjb_saper wrote: |
Imagine an accounting application with a central office and 1000 stores.
Now depending on how the processes are written I can easily imagine the need for an app to behave like mq_rookie mentioned...
Enjoy |
Thanks to all for the replies..
Yes my application is similar to what fjb_saper mentioned. I must send different information to each getter. I am releatively new to MQ. So I am not sure whether a Pub/Sub type design can achieve the same.
If that is not possible I will go with the solution from PeterPotkay.
Is there any benefit in going for some threading in which each thread write to each queue?
Thanks again for your suggestions |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 26, 2007 8:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Pub/Sub would be of some value if, for example, several of the destination queues got the same message.
In a retail scenario, this might be for example a price change that was different for different regions. All stores in each region would need the same price change, but different regions would need different price changes. So you could publish the price changes under topics for each region. Then all the stores would subscribe to regional topics, as well as store specific topics.
Then the price change notification store would only have to publish one message for each region.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mq_rookie |
| Posted: Fri Oct 26, 2007 9:05 am Post subject: |
|
|
Newbie
Joined: 25 Oct 2007
Posts: 4
|
| jefflowrey wrote: |
Pub/Sub would be of some value if, for example, several of the destination queues got the same message.
In a retail scenario, this might be for example a price change that was different for different regions. All stores in each region would need the same price change, but different regions would need different price changes. So you could publish the price changes under topics for each region. Then all the stores would subscribe to regional topics, as well as store specific topics.
Then the price change notification store would only have to publish one message for each region. |
Well in that case Pub/Sub may not fit because I don't see any chance to have same information for even two end poits.
From all the replies I believe i could go with
MQCONN
MQOPEN1
MQPUT1
MQCLOSE1
MQOPEN2
MQPUT2
MQCLOSE2
.
.
MQDISC
Thank you verymuch  |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 26, 2007 9:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Nope.
Do this:
MQCONN
MQPUT1 to Q1
MQPUT1 to Q2
MQPUT1 to Q3
.
.
.
MQPUT1 to Q1000
MQDISC
MQPUT1 is a call that combines MQOPEN, MQPUT and MQCLOSE. Its faster than doing the 3 calls seperatly. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
