| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Name Resolution Query |
« View previous topic :: View next topic » |
| Author |
Message
|
| ChrisW |
 Posted: Thu Jun 13, 2013 3:30 am Post subject: Name Resolution Query |
 |
|
Voyager
Joined: 20 May 2001
Posts: 78
Location: UK
|
Anyone got any ideas what is happening here? Its an existing working connection sending from Queue Manager
QM1 through QM2 and onwards to QM3 over intersecting clusters.....
QM1 sends to QM2 over a cluster(CL1) to queue QA1. The definition of QA1 on QM2 is:
DEFINE QA(QA1) TARGQ(QA1) CLUSTER(CL1) DEFBIND(NOTFIXED) - Note same name!
QA1 is also defined on QM3 in cluster CL2 so on QM2 DISPLAY QC(*) shows both instances.
I would expect (from Application Programming Guide) that the Blank or local queue manager/Alias queue would
be hit with "Must not resolve to an alias queue" applying. But it all works OK (well there are intermittant
problems with performance which is why I'm looking at this but no messages lost)
Solaris 6.0.1.1.
Many thanks, Chris. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jun 13, 2013 3:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
QALIAS can't hold a queue manager name, so the fact that it's blank is, um, working as designed.
QALIASes are only used to resolve Object Queue Names and can not affect Object Queue Manager Names.
So if you send a message to QA1/QmgrB, the qmgr will resolve QA1 to the name QA1, and then resolve QmgrB to whatever transmission queue is appropriate.
Note that the definition of your QA also says that it should be shared in the cluster CL1. So any qmgr that is a member of CL1 will see a definition of it as existing on QM2, and can forward messages to QM2 over CL1.
The fact that you're resolving to the same name doesn't cause loops because names are only resolved once (at each hop), and there's a documented order of how different types of objects are checked. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jun 13, 2013 3:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The application connecting to QM1 'opens' QA1 across the cluster - presumably the application is authorised to the SYSTEM.CLUSTER.TRANSMISSION.QUEUE (S.C.T.Q), which isn't a good idea (but that's another topic) - and QM2 resolves where the actual queue is, i.e. on QM3 but in a different cluster. The QA is not resolving to another QA, it's resolving to a QL declared as a cluster resource.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| ChrisW |
| Posted: Thu Jun 13, 2013 4:57 am Post subject: |
|
|
Voyager
Joined: 20 May 2001
Posts: 78
Location: UK
|
| Thanks for the responses. |
|
| 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
|
|
|
|
