| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| SOLVED: Overlapping cluster design issue |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqjeff |
 Posted: Mon Jul 16, 2012 3:38 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| girish_tharwani wrote: |
| Typically when I design a system, I avoid asking requesting app to populate the "ReplyToQmgr" field. I let MQ fill it when the request message leaves the requestor side qmgr (QM1). |
Typically, this enforces a reliance on the actual real name of the queue manager.
There is a school of thought that says applications should never use real names for any objects at all.
As bruce says, in your case it's strictly necessary to follow that notion, even if it's not strictly necessary in many cases. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jul 16, 2012 8:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| girish_tharwani wrote: |
| Typically when I design a system, I avoid asking requesting app to populate the "ReplyToQmgr" field. I let MQ fill it when the request message leaves the requestor side qmgr (QM1). |
Typically, this enforces a reliance on the actual real name of the queue manager.
There is a school of thought that says applications should never use real names for any objects at all.
As bruce says, in your case it's strictly necessary to follow that notion, even if it's not strictly necessary in many cases. |
You've offered us no actual object definitions to look at. I can only speculate that you've created the very quagmire that you now complain about.
Name resolution is complicated. The subject is covered in multiple documents - the APR, APG, Intercomm, Queue Manager Clusters manuals.
_________________
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 |
|
|
| girish_tharwani |
| Posted: Tue Jul 17, 2012 10:52 pm Post subject: SOLVED: Overlapping cluster design issue |
|
|
Voyager
Joined: 01 Aug 2001
Posts: 88
Location: Pune, India
|
On QM1a
DEFINE QL(REPLYQ)
DEFINE QR(QM1a.C1) RNAME('') RQMNAME(QM1a) CLUSTER (C1)
DEFINE QR(REPLYQ.ALIAS) RNAME(REPLYQ) RQMNAME(QM1a.C1)
on QM1b
DEFINE QL(REPLYQ)
DEFINE QR(QM1b.C1) RNAME('') RQMNAME(QM1b) CLUSTER (C1)
DEFINE QR(REPLYQ.ALIAS) RNAME(REPLYQ) RQMNAME(QM1b.C1)
on QM2
DEFINE QL(REQUESTQ) CLUSTER(C1)
Reqeustor app connecting to QM1a/QM1b and putting request messages on REQUESTQ, specify replytoQ=REPLYQ.ALIAS and leave replytoqmgr blank
When messages arrive on REQUESTQ, messages have replytoq=REPLYQ and replytoqmgr=QM1a.C1 or QM1b.C1 (depending on where the messages came from)
Responder app uses replytoq and replytoqmgr information when sending the replies. Replies go back to same qmgr where the requests came from and travel only on C1 channels, not on C2 channels. |
|
| 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
|
|
|
|
