| Author |
Message
|
| MQWays |
 Posted: Sun Nov 02, 2008 5:18 am Post subject: Multiple channels for single remote queue |
 |
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
Hi,
Is it possible to have multiple receiver channels on a queue manager that points to the same local queue.
For e.g.
1) QM1 (Q Mgr) has a sender channel QM1.QM3 for remote queue TEST
2) QM2 (Q Mgr) has a sender channel QM2.QM3 for remote queue TEST
3) QM3 (Q Mgr) has two receive channels
QM1.QM3 for local queue TEST
QM2.QM3 for local queue TEST
All the above Q Mgrs are in different physical locations. Is this a valid configuration ? |
|
| Back to top |
|
 |
| harish_td |
| Posted: Sun Nov 02, 2008 5:55 am Post subject: |
|
|
Master
Joined: 13 Feb 2006
Posts: 236
|
| It is valid. But why would you want to have a setup like that? |
|
| Back to top |
|
|
| MQWays |
| Posted: Sun Nov 02, 2008 6:10 am Post subject: |
|
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
On the receiving end, the business type of the transaction is the same. That's why we prefer keeping one queue for all different clients.
Or do you suggest keeping a unique queue for every client even though the transaction type is the same. Design Question .... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Nov 02, 2008 6:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
RCVR channels (along with the partner SNDR channels) connect QMs, not queues.
It is perfectly valid to have 1 QM with 100 RCVR channels from 100 other QMs. All the RCVR channels can be putting to the same queue, or 2,534 different queues concurrently.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| MQWays |
| Posted: Sun Nov 02, 2008 6:19 am Post subject: |
|
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
Thanks.
From design perspective, can any restriction or maintenance overhead be anticipated if a single local queue is used for multiple clients.
Wouldn't segregation based on the clients (i.e. multiple queues) give more control in unforeseen situations.
From clients, I mean different business entities (companies) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Nov 02, 2008 7:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| From design perspective... |
I'm guessing that you are asking if it is better to have a single queue serving many client applications. In this case, the issue is whether the consuming server application can keep up with the message workload.
| Quote: |
| Wouldn't segregation based on the clients (i.e. multiple queues) give more control in unforeseen situations. |
It is possible that you can have multiple consuming applications servicing the same application queue. (Message affinity might preclude this.)
The client request message contains the identity of the reply-to-queue and qmgr where the reply message is to be returned by the server application; so there will likely be no need to have a specific queue for each client.
It is difficult, if not impossible, to design an application that forsees unforseen situations. Having multiple queues where one will do seems simpler to implement (saving time and money). If some future requirement dictates a unique queue for each entity, alter the design then.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Nov 02, 2008 8:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I tend to favor multiple queues over a single queue. Queues are "cheap". Trying to figure what one component is misbehaving out of 20 sharing a single queue can be tough. Having a separate q for each process allow you to set up distinct monitoring and alerting for each. You can easily see the difference of throughput between the queues using out of the box MQ statistics. It becomes a lot harder to see who is doing what when the "share a queue" concept gets taken to the extreme. Having said that you have to avoid queue creep, don't take it to the other extreme and find yourself with 8 million queues to manage.
There is definitely an art to queue design. There are not exact rules. You need detailed business and application requirements to come to an educated conclusion.
Should you use one q or many? It depends.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Nov 02, 2008 12:58 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you are in a request / reply pattern where the request can easily be traced back to the issuing application I'd go with a single clustered queue for processing and load balancing. Make sure however that you have the possibility to manage the sources... (each source it's own channel etc...) so that you can cut them off individually should the need arise 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Nov 02, 2008 1:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
While agreeing with the points made by my most esteemed associates, I'd add that additional channels (which link qmgrs not queues as previously pointed out) are commonly used to provide multiple routes between queue managers. Again, this is most commonly done to either split network load or split low priority traffic onto slower or alternative links to keep other routes free for priority traffic.
It all depends on your situation and requirements; there's no "right" answer, just a couple of wrong ones!  This cat can be skinned in a wide variety of ways.
(With apologies to any cat lovers in the readership...  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQWays |
| Posted: Tue Nov 04, 2008 4:48 am Post subject: |
|
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
hi fjb_saper,
Could you please shed some more light no how request / reply pattern can tell us about who is the source (application/sender) of the message. |
|
| Back to top |
|
|
| jsware |
| Posted: Tue Nov 04, 2008 5:58 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| MQWays wrote: |
| Could you please shed some more light no how request / reply pattern can tell us about who is the source (application/sender) of the message. |
Every message you put onto a queue has a message descriptor (MQMD). In this structure there are two fields ReplyToQ and ReplyToQMgr. These effectively provide a "return address" for the response.
Thus when your server application receives a message from the client, it can perform an MQPUT1 API call to effectively say "put a message onto ReplyQ@ReplyQMgr" and the QMgr will work out what to do (assuming that there is a route back to the client qmgr via MQ clusters, qmgr aliases, appropriately named QMgrs/whatever.
Thus APP1 using QM1 can put a message to APP1.REQUESTQ and specify APP1.REPLYQ as the response queue.
APP2 using QM2 can put a message to APP2.REQUESTQ and specify APP2.REPLYQ as the response queue.
The request q's are QREMOTEs which "point" at APP3.REQUESTQ on QM3. There does not need to be (nor can be) an APP3.REPLYQ which points at both APP1.REPLYQ@QM1 and APP2.REPLYQ@QM2 at the same time.
APP3 uses the MQMD.ReplyToQ and MQMD.ReplyToQMgr fields to know where to send the message back (incidentally, if APP1/2 leave the MQMD.ReplyToQMgr, the QM they are connected to fills in the blanks with its own name). Thus APP3 can do an MQPUT1 specifying {MQMD.ReplyToQ}@{MQMD.ReplyToQM} and the MQPUT1 will put the reply directly onto an xmitq called QM1/QM2 (assuming standard distributed queueing) and MQ will deliver it to APP1.REPLYQ and APP2.REPLYQ as necessary.
Also remember to honour the MQMD.Report settings which indicate what to do with the MQMD.MsgID/CorrelID values in the response. These allow a client to match responses with requests (e.g. by matching the CorrelID of the response to the MsgID of the request which is the default).
With regards to single/multiple request queues, you could have QREMOTE(APP1.REQUESTQ) deliver to QALIAS(APP3.APP1.REQUESTQ) which is an alias for APP3.REQUESTQ. Then if you want to separate APP1 out from APP2, you can replace QALIAS(APP3.APP1.REQUESTQ) with a QLOCAL of the same name and read them separately from that queue. Thus APP1 does not know whether APP3 has separated out its messages or not. APP1 always puts to a queue called APP1.REQUESTQ.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
|
|
