| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Qremote Resolving to a local queue possible? |
« View previous topic :: View next topic » |
| Author |
Message
|
| chengka |
 Posted: Thu Feb 20, 2014 3:37 pm Post subject: Qremote Resolving to a local queue possible? |
 |
|
Newbie
Joined: 16 Feb 2007
Posts: 4
|
I would like the ability to put to a QALIAS which resolves to a queue which may be local, or remote. Clustering is not allowed.
Our basic idea is to use qmgr aliases to move masses of queues, rather then changing masses of objects. It seemed to me I should be able to create this crazy structure.
On LOCALQM
QLAIAS QA01 Baseobject(QR01)
QREMOTE QR01 RNAME(QL01) RQMNAME(QMALIAS)
QREMOTE QMALIAS RQMNAME(LOCALQM)
QLOCAL QL01
So this crazy circular logic would result in a put to QA01 resulting on QL01 on the same queue manager. If it worked, we could force all puts to a remote queue just by changing the definition for QMALIAS. Only problem is I get a 2091 because there is no XMITQ associated with QR01. Is it possible to do what I proposed?
Thanks,
Ken |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Feb 20, 2014 3:58 pm Post subject: Re: Qremote Resolving to a local queue possible? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| chengka wrote: |
| I would like the ability to put to a QALIAS which resolves to a queue which may be local, or remote. |
Yes, a QAlias may have as its TARGET a QLocal or QRemote.
| chengka wrote: |
| Our basic idea is to use qmgr aliases to move masses of queues, rather then changing masses of objects. |
What do you mean by 'move masses of queues?'
_________________
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 |
|
|
| chengka |
| Posted: Fri Feb 21, 2014 7:09 am Post subject: Re: Qremote Resolving to a local queue possible? |
|
|
Newbie
Joined: 16 Feb 2007
Posts: 4
|
| bruce2359 wrote: |
What do you mean by 'move masses of queues?' |
Consider a case where the message producer and the consumer may or may not reside on the same queue manager. At times they may be together and at times they are on seperate queue managers. There may be 20 queues which represent a consumer. The producer will put to 20 objects and if the conumer is local at that time, we would have to alter 20 QALIAS to target a local queue. This may seem trivial, but there are many consumers and producers. If there are 25 QALIAS for another producer to the same consumer, now we have 45 objects to alter.
My proposal involves leaving all the QALIAS pointing to a QREMOTE and use a queue manager alias to route the messages. So in this case, all 45 QALIAS( 20+25) would point to a queue remote with a queue manager alias as the rqmname. If the consumer is remote, we alter the queue manager alias to refer to the remote qmgr, if the consumer is local, we alter the qmgr alias to reflect the local queue manager and all 45 objects are done.
I know this sounds ridiculous, but please humor me. I'm hoping this group of experts can help me decide if it possible to construct this path with MQ? A better solution would be even better  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 21, 2014 8:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I doubt I'll be able to humor you.
So, your consumers are free to move from one qmgr to another whimsically? Frequently? Odd.
Queue-manager aliases (aliaii?) are used to resolve qmgr names AFTER a message has been sent down the network to a remote qmgr MCA, OR AFTER a message has been received from the network, to resolve the qmgr name in the XQH.
In this sense, 'resolve' means to correct the RQMNAME in the XQH (transmission queue header), OR to move the message to an xmit queue to move the message message further down the network.
A best-practice is to give application developers an alias (QAlias) name for them to use at MQOPEN, and not the real name of the local queue or the real QRemote name of the queue. This allows us sysadmins to change the TARGET of the QAlias from a QRemote to a QLocal (or QLocal to QRemote) to meet our changing requirements.
The best-practice is for applications to only specify in the MQOD the queue-name, and NOT the combination of queue-name AND qmgr-name, at MQOPEN. If the app specifies the qmgr-name, the name-resolution software will presume that the qmgr-name supplied will be an XMITQ.
I suppose you could write a script of some kind that could scan through your object definitions, and change the the targets of the QAlias definitions to meet your requirements.
I recommend that you research 'name resolution' in the APG, APR, and Intercommunications, manuals to get an understanding of what and how the qmgr deals with names of things.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Feb 21, 2014 9:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
consumers generally don't randomly decide what queue manager they feel like connecting to.
They generally connect to well known locations.
It otherwise sounds like you really want a pub/sub setup rather than a producer/consumer setup. everything you want to do would be handled by publishing/subscribing to topics, rather than using queues. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Feb 21, 2014 9:43 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
what determines were the consumers and producers are?
what scenario are you trying to achieve?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| chengka |
| Posted: Fri Feb 21, 2014 1:47 pm Post subject: |
|
|
Newbie
Joined: 16 Feb 2007
Posts: 4
|
| mqjeff wrote: |
consumers generally don't randomly decide what queue manager they feel like connecting to.
They generally connect to well known locations.
It otherwise sounds like you really want a pub/sub setup rather than a producer/consumer setup. everything you want to do would be handled by publishing/subscribing to topics, rather than using queues. |
I completely agree with you, however our experience with pubsub is somewhat limited and confined to managed subscriptions.
Thanks to all the responders. I appreciate your input. |
|
| 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
|
|
|
|
