| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Cluster qmgr topology and relaying |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Tue Dec 11, 2007 11:12 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
Read up on the qmgr alias in the intercommunications manual. 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| rconn2 |
| Posted: Tue Dec 11, 2007 2:56 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
I did. It says:
"The remote queue definition contains the names of the target queue and queue manager, and optionally... the transmission queue to be used. If no transmission queue name is provided, the queue manager uses the queue manager name, taken from the remote queue definition for the transmission queue name. If... not defined, but a default transmission queue is defined, the default transmission queue is used."
It does not say the transmission queue from a queue manager alias will be used when an xmitq isn't defined in the remote defn. And, this wouldn't work (further resolving to an alias qmgr and xmitq) when I tested your technique.
A multihop does work by just putting the xmitq for a channel to the middleman qmgr in the remote q defn.
So, according to a strict reading of the Intercommuncations Guide, your technique won't work, and it won't work when tested (I followed your code exactly). If it should work, I'd like to understand and have that knowledge. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 11, 2007 9:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
The reason you need the qmgr alias is that you can do a put on a message with qname and qmgr name on the message descriptor without using a remote queue.(request/reply) This will allow the qmgr to resolve to the xmitq and to the hop/relay...
| Quote: |
| If no transmission queue name is provided, the queue manager uses the queue manager name, taken from the remote queue definition for the transmission queue name. |
This means that the qmgr will try and further resolve the destination. If there is no xmitq with the qmgr name and no qmgr alias and no default xmitq or (the qmgr is the name of the local qmgr and the dest queue does not exist locally ) you have reached a point of failure...
Note that the qmgr alias always has either an xmitq populated or leads to further destination resolution on the same qmgr.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rconn2 |
| Posted: Wed Dec 12, 2007 7:24 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
My understanding is there are two different techniques...
1. qmgr alias. An app does a put w/ both qname and qmgr name. The alias kicks in on the qmgr name and resolves to a qmgr name and the xmitq to use. That xmitq could go to a hop server (or wherever).
2. remote q denition. An app does a put w/ just the qname. The remote definition kicks in and, as above, resolves to a qmgr name and the xmitq to use.
I've tested both #1 and #2 to verify, and they work.
3. Maybe I misunderstood, but I thought you suggested mixing both #1 and #2 by leaving the xmitq blank in the remote definition. Then the qmgr specified in the remote would match a qmgr alias which then would provide the xmitq.
app:qname --> rq defnition:qmgr -->alias qmgr:xmitq.
I haven't been able to get this to work as the alias doesn't kick in. The quote from the manual is about a remote definition: if no xmitq, then mq looks for an xmitq matching the qmgr name else a default xmitq. It doesn't say mq will try to match the qmgr name w/ an alias -- and I couldn't get that to work which seems to confirm.
We're following technique #2 above which works, so #1 and #3 aren't strictly needed. But, I can see there could be a use for #3 -- i.e. everything could be switched over to another destination qmgr and xmitq just by altering an alias (another level of indirection in the definitions).
So, the kernel of the question is: if an xmitq isn't defined in a remote q defn, and there exists an alias for the qmgr specified in that remote defn, will that alias be used to resolve to the xmitq?
Or, does mq ignore qmgr alias' when using a remote q definition -- as seems to be the case? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 12, 2007 7:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rconn2 wrote: |
| The quote from the manual is about a remote definition: if no xmitq, then mq looks for an xmitq matching the qmgr name else a default xmitq. It doesn't say mq will try to match the qmgr name w/ an alias -- and I couldn't get that to work which seems to confirm. |
No, if the xmitq of a remote queue definition is blank the queue manager will look for a queue with the name of the target queue manager. It can't tell if that's an alias, a multi-hop or what - it just looks for the name. This technique works, I've used it extensively.
| rconn2 wrote: |
| So, the kernel of the question is: if an xmitq isn't defined in a remote q defn, and there exists an alias for the qmgr specified in that remote defn, will that alias be used to resolve to the xmitq? |
Yes.
| rconn2 wrote: |
| Or, does mq ignore qmgr alias' when using a remote q definition -- as seems to be the case? |
No.
The mechanism for resolving routes in the absense of a specified xmitq is the same. It doesn't matter if the lack of specified queue is due to a blank xmitq parameter on a remote queue definition or a lack of remote queue definition.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Wed Dec 12, 2007 1:25 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
WindowsXP Pro, SP2
Websphere MQ v. 6.0
1. I created 3 qmgr's: QMGR1, QMGR2 and QMGR3 through runmqsc.
On QMGR1:
def qr(TESTQ) rname(TESTQ) rqmname(QMGR3) replace
def qr(QMGR3) rqmname(QMGR3) rname(' ') xmitq(QMGR2) replace
def ql(QMGR2) usage (xmitq) replace
def chl(QMGR1.QMGR2) chltype (sdr) conname('127.0.0.1(1417)') xmitq(QMGR2) replace
On QMGR2:
def chl(QMGR1.QMGR2) chltype(rcvr) replace
def chl(QMGR2.QMGR3) chltype(sdr) conname('127.0.0.1(1418)') xmitq(QMGR3) replace
def ql(QMGR3) usage(xmitq) replace
On QMGR3:
def chl(QMGR2.QMGR3) chltype(rcvr) replace
def ql(TESTQ) replace
2. In MQ Explorer, when I put a message to the remote TESTQ on QMGR1, I get the following error:
----------
Transmission Queue Type Error
Event name: Transmission Queue Type Error.
Reason code in MQCFH: MQRC_XMIT_Q_TYPE_ERROR (2091, X'82B').
Transmission queue not local.
Event description: On an MQOPEN or MQPUT1 call, a message is to be sent to a remote queue manager. The ObjectName or ObjectQMgrName field in the object descriptor specifies the name of a local definition of a remote queue but one of the following applies to the XmitQName attribute of the definition. Either:
XmitQName is not blank, but specifies a queue that is not a local queue, or
XmitQName is blank, but RemoteQMgrName specifies a queue that is not a local queue This also occurs if the queue name is resolved through a cell directory, and the remote queue manager name obtained from the cell directory is the name of a queue, but this is not a local queue.
Event type: Remote.
Platforms: All.
Event queue: SYSTEM.ADMIN.QMGR.EVENT.
----------
3. When I put a message to the remote TESTQ on QMGR1 through JMS, I get the following error:
----------
javax.jms.InvalidDestinationException: MQJMS2008: failed to open MQ queue TESTQ
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2091
----------
4. When I change the qr for TESTQ on QMGR1 to set the xmitq to QMGR2, then messages get multi-hopped successfully.
Leaving out the xmitq on the remote q definition does not resolve to the qmgr alias for the rqmname's xmitq. I've tried different variations, all with the same negative result. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 12, 2007 3:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
Leaving the xmitq blank might only be effective if you are part of an MQ Cluster...  or if the message has already been put? (i.e. coming in from a different qmgr...)
Look at following set up:
qmgr1:
cluster alias:
def qr(MYCLUSTER) rname(' ') rqmname(' ')
remote queue
def qr(myclusq) rname(myclusq) rqmname(mycluster) xmitq(' ')
qalias
def qa(myalias) targq(myclusq)
myclusq lives on qmgr2
qmgr1 and qmgr2 are part of the same cluster.
Put to myalias
This should work (Ver 5.3)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rconn2 |
| Posted: Wed Dec 12, 2007 8:04 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
fjb_saper - thanks for staying w/ this. Clusters have already been ruled out in this thread because jefflowrey said so!  Seriously, he succinctly explained that clusters aren't appropriate when spanning network boundaries.
In any case, if we were using clusters and since each cluster qmgr would need to be able to connect to each other, we wouldn't have the need to hop through an intermediary qmgr. We went to a DQM because of this need to hop.
Just using a qr with the xmitq set to the middleman qmgr works well. I pursued also using a qmgr alias, since you and Vitor said it would work, and just to have that trick up my sleeve in case an extra level of declarative indrection might be useful in the future. For example, the qmgr alias would allow switching many qr's at once to use a different xmitq.
So, the conclusion remains that it doesn't work: a remote queue definition that leaves out the xmitq will not resolve by matching the rqmname to a qmgr alias that does have an xmitq defined.
Vitor - if you still disagree with the above, please let me know what may be wrong to cause the previous posted setup to fail when putting a message. Are you sure you're not mistaken? |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Thu Dec 13, 2007 12:14 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
There's always the trick of defining a clustered qma!
QMA is clustered with QMB in cluster CLUS
QMB has an xmitq pointing to QMC
on QMB def qr(QMCALAIS) rqmname(QMC) rname(' ') cluster(CLUS)
now the QR QMCALIAS is visible (and more to the point USABLE) from QMA
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 13, 2007 2:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rconn2 wrote: |
| Vitor - if you still disagree with the above, please let me know what may be wrong to cause the previous posted setup to fail when putting a message. Are you sure you're not mistaken? |
IMHO the problem is the alias on QMGR1. The QR should not have an entry in RQMNAME, so messages go onto the queue addressed for QMGR3.TESTQ, the route to QMGR3 is provided by the alias (i.e go down the xmitq QMGR2 and ask again), it reaches QMGR2, asks again, finds the xmitq QMGR3 and is delivered.
What the current set up does is the message rolls into the queue QMGR1.QMGR3 but the RQMNAME entry is forcing it to effectively resolve against itself. Now it's a bit odd, given that it quotes an xmitq, but I have reproduced your error and fixed it by taking the entry out!
(MQ v6.0.2)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Thu Dec 13, 2007 7:43 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
This is the original and doesn't work:
def qr(TESTQ) rname(TESTQ) rqmname(QMGR3) replace
def qr(QMGR3) rqmname(QMGR3) rname(' ') xmitq(QMGR2) replace
I took rqmname out from the alias and it gives the same error:
def qr(TESTQ) rname(TESTQ) rqmname('QMGR3') replace
def qr(QMGR3) rqmname(' ') rname(' ') xmitq(QMGR2) replace
Taking the rqmname out of the remote q couldn't work because when putting a message to TESTQ there'd be nothing that would couple TESTQ to QMGR3:
def qr(TESTQ) rname(TESTQ) rqmname(' ') replace
def qr(QMGR3) rqmname(QMGR3) rname(' ') xmitq(QMGR2) replace
Note: I'm using Websphere explorer to put a test message and a JMS program. Neither specifies the destination qmgr, just the queue. Per the documentation, a qmgr alias requires both the qmgr and queue be specified. The idea was that the remote queue defnition would provide the qmgr and the alias the xmitq.
Are you sure you're not just using the alias by putting to a specfied qmgr and queue and bypassing the remote q defnition entirely? In any case, I did as you suggested, and it still doesn't work.
Just using:
def qr(TESTQ) rname(TESTQ) rqmname('QMGR3') xmitq(QMGR2)
without a qmgr alias does work. I still have to conclude that a remote q defnition without an xmitq will not lookup the xmitq from a qmgr alias. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 13, 2007 8:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rconn2 wrote: |
| I still have to conclude that a remote q defnition without an xmitq will not lookup the xmitq from a qmgr alias. |
Damn. I'll have to stop using it now. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 13, 2007 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| Vitor wrote: |
| rconn2 wrote: |
| I still have to conclude that a remote q defnition without an xmitq will not lookup the xmitq from a qmgr alias. |
Damn. I'll have to stop using it now. |
As I said the blank xmitq with a qmgr alias seems to work only when the qmgr is member of an MQ Cluster...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rconn2 |
| Posted: Thu Dec 13, 2007 1:52 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
Vitor - no, you should continue using "it", whatever "it" is.
Seriously, this thread provided the architectural solution for us and has been a great learning exercise. I sincerely appreciate everyone's help. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 13, 2007 4:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| rconn2 wrote: |
So, the kernel of the question is: if an xmitq isn't defined in a remote q defn, and there exists an alias for the qmgr specified in that remote defn, will that alias be used to resolve to the xmitq?
Or, does mq ignore qmgr alias' when using a remote q definition -- as seems to be the case? |
Take a look here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzae.doc/ic10650_.htm
| Quote: |
| When a remote queue definition exists, no alias definitions are referenced. The queue name supplied by the application is resolved to the name of the destination queue, the remote queue manager, and the transmission queue specified in the remote queue definition. For more detailed information about queue name resolution, see Queue name resolution. |
You should always code an XMITQ in your remote q defs, if just for clarity's sake. You don't need to code the XMITQ parm for remote q defs in a cluster though if a clustered QM Alias can be resolved to, which is a bit inconsistent to the above quote from the manual.
Even if you code the remote q def with the XMITQ parm set to QM3, you should still define the QM Alias for QM3 on QM1 for those apps that will be replying to the MQMD ReplyToQ and ReplyToQM of a request message instead of using a predefined remote q def.
| JosephGramig wrote: |
| PeterPotkay wrote: |
Every PR needs to be able to get to both FRs
Each FR needs to be able to get to the other FR.
But not every PR needs to talk to every other PR. |
Well, if one PR cannot talk to another PR that hosts a queue in the cluster then the PR QMGR will build an automatic channel to it and that channel will go into retry and messages will start piling up in the S.C.T.Q and that will adversely affect everything that QMGR is trying to talk to in that cluster (and now that I read this again, every cluster it talks to).
Every QMGR in a cluster must be able to talk to every other QMGR in that cluster because it might and if it can, that will get you bad results.
|
You didn't quote me completely Joseph.
| PeterPotkay wrote: |
Every PR needs to be able to get to both FRs
Each FR needs to be able to get to the other FR.
But not every PR needs to talk to every other PR. A PR will create an auto CLUSSNDR channel to another PR only if it needs to send an application's message to it. If PR1 never needs to send a message to PR2, it doesn't matter that PR1 can't talk to PR2.
|
Maybe we'll have to agree to disagree. I still feel that if PR1 has no reason to send a message to PR2, then it will never try and create a channel to PR2 so technically its possible to have both of these in a cluster even though PR1 and PR2 can't talk.
| JosephGramig wrote: |
Well, if one PR cannot talk to another PR that hosts a queue in the cluster then the PR QMGR will build an automatic channel to it and that channel will go into retry and messages will start piling up in the S.C.T.Q and that will adversely affect everything that QMGR is trying to talk to in that cluster (and now that I read this again, every cluster it talks to).
|
IF the channel was retrying the cluster workload algorithm would not send any messages to that QM so nothing would pile up.
Anyway, the bottom line is that while every PR in a cluster may not need to talk to another PR, ever, I wouldn't recommend designing a cluster like that anyway either. One should use overlapping clusters or regular SNDR/RCVR channels. As its been noted clusters spanning funky network topologies can get hairy fast.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
