| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Clustering & the MQ/IMS-bridge |
« View previous topic :: View next topic » |
| Author |
Message
|
| JT |
 Posted: Tue Aug 10, 2004 11:09 am Post subject: Clustering & the MQ/IMS-bridge |
 |
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Hi,
Does anyone know if the MQ/IMS-bridge supports clustering? If so, can you provide some guidance on what we may have over-looked?
We have 2 Solaris queue managers (full repos) in a cluster with a single M/F queue manager (partial repos). The configuration is working just fine.
When we attempted to include the MQ/IMS-bridge into the configuration, we encountered a problem. Heres' our understanding of the issue: request messages sent to the MQ/IMS-bridge on the OS/390, from the Solaris queue managers (messages are built by WBIMB, with an IIH header), are retrieved successfully by the bridge, which then removes all semblance of MQ and delivers the payload to the IMS application. When the IMS application completes its processing and returns control, the MQ/IMS-bridge re-attaches the MQ headers and puts the reply message to the queue specified in the ReplyToQ field of the request message. Apparently it also uses the ReplyToQMgr identified in the message descriptor of the request. The ReplyToQMgr field contains the name of the Solaris queue manager that sent the request message.
Doesn't this negate the clustering feature by directing the reply message to a particluar Solaris queue manager? On the open, shouldn't the bridge use a queue manager name that's blank when sending the reply message? Is there a way to prevent the Solaris queue manager from setting a default ReplyToQMgr value if it's been intentionally left blank by WBIMB?
Appreciate any assistance. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Aug 10, 2004 11:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, you have a sending application that creates a request message.
That sending application (in this case, WMQI) is bound to a particular queue manager. You might have two sending applications, each bound to one of your two queue managers.
It doesn't usually make sense for an application to receive a reply message for a request it did not make - which is what could/would happen if the ReplyToQueueManager was not observed by the IMS Bridge.
Does it make sense in your case, that WMQI #1 could send a request and WMQI #2 would process the reply for that request?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JT |
| Posted: Tue Aug 10, 2004 11:58 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Jeff,
Why not? The message flows processing the reply messages are independent of the request messages and the message flows that created them (there is no state maintained). Therefore any broker/queue manager hosting a copy of the reply message flow should be considered a candidate to process the reply message returned from the M/F queue manager, say QM3.
How about a scenario where a request message created by a message flow hosted by one of the Solaris broker/queue managers, let's say QM1, is sent to the host queue manager, QM3, and makes it's way to the MQ/IMS-bridge. While the IMS application is processing the transaction, queue manager QM1 becomes unavailable.
Wouldn't I want a reply message flow, hosted by the other Solaris broker/queue manager, say QM2, to process the reply? It can't if the MQ/IMS-bridge is sending the reply back to the originator of the request.
Thanks for responding. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 10, 2004 12:03 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In a typical request/reply pattern, the requesting application (client) puts the request message, and then executes a get with wait on Correlation ID to receive the reply. This is because the sending application usually needs to do something specific with the reply, and it needs to maintain it's own internal state until the reply comes back. For instance, in a web form entry system, the requesting application needs to put information into the HTTP reply for the specific web client.
How is the other instance of the application supposed to know the correct correlation ID to wait for?
If, as you say, there really is no application-side state being maintained... then I wonder why you are using a request/reply pattern?
Just use regular point to point asynchronous, and don't populate the request header information. Then the IMS Bridge should not populate the queue manager field, and you'll get the load balancing you're after.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| JT |
| Posted: Tue Aug 10, 2004 1:25 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Jeff,
I see I didn't explain it well, sorry for the confusion. Let me see if I can define it better.
WEB-----http-----WAS-----mq-----WBI(2)-----mq-----MQ/IMS bridge-----IMS Application
A WBI request message flow, hosted on multiple brokers, receives an XML-structured message from a WAS application, via MQ. The request message flow transforms the message to COBOL and forwards the request to the back-end IMS application on the mainframe. The COBOL reply message from the host application is received by a WBI reply message flow, also hosted on multiple brokers, and transformed back to XML and sent to the WAS application where a MDB is waiting to consume it. When the MQ/IMS-bridge is not in the equation (some apps have no need for the bridge as they are MQ-aware), all works as designed. However, some of our legacy applications are dependent upon the bridge to do the "messaging" for them.
We see no reason why the reply message has to be processed by the broker that initiated the request. We'd like to use clustered queues, in conjunction with the MQ/IMS-bridge, to handle the load-balancing and provide for an "active/active" WBI environment. However, the bridge is acting contrary to this by sending the reply to the queue manager where the request originated.
Hope this clears up my earlier post(s). |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 10, 2004 4:59 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Hi JT, the bridge is acting properly in that it must assume a request message coming in needs a reply message going out to a specific QM. The vast majority of Request/Reply models operate under the assumptions that Jeff laid out.
Having said that, your design is good if the "reply" message can go back to either QM1 or QM2. Your point is valid that if QM1 sends the request to QM3 and then takes a dirt nap while QM3 is formulating the response, it would be nice to send the reply back to the cluster, rather than a specific QM.
...send the reply back to the cluster....
Well, there are 2 ways to do this.
1. On QM3, create a QMAlias for both QM1 and QM2 that will erase the destination QM name from a message.
| Code: |
DEF QREMOTE (QM1) +
RQNAME( ) +
RQMNAME( ) +
XMITQ ( )
DEF QREMOTE (QM2) +
RQNAME( ) +
RQMNAME( ) +
XMITQ ( )
|
Any message leaving QM3 with QM1 or QM2 in the destination QM field will have that wiped to blank, and the message will be free to round robin in the cluster. The drawback to this is you will never be able to send a message from QM3 to specifically QM1 or QM2, and that need may arise in the future.
2. On QM1 and QM2, take advantage of ReplyTo Aliases. Lets say your real ReplyToQueue is REPLY.TO.QUEUE.JT. You have this queue on both QM1 and QM2. Define a ReplyTo Alias queue on both QM1 and QM2 as follows:
| Code: |
DEF QREMOTE (REPLY.TO.QUEUE.KRAMER) +
RQNAME(REPLY.TO.QUEUE.JT) +
RQMNAME(ClusterName) +
XMITQ ( )
|
Now code the app to specify the MQMD_REPLYTOQUEUE as REPLY.TO.QUEUE.KRAMER. The ReplyTo Alias queue will kick in, and the request message will leave QM1 or QM2 with REPLY.TO.QUEUE.JT as the ReplyToQueue and ClusterName as the ReplyToQueueManager. You could also try leaving RQMNAME blank in the ReplyTo Alias, since the replying QM is part of the cluster, it may not even be needed. But then again it might (MQ may bark at a request message with no ReplyToQM). I always have filled it in, so let us know if it works with that field blank. The Intercommunication manual seems to indicate blank will be OK.
I like this method better if you forsee ever the possability of needing QM3 to specifically send message back to QM1 or QM2. I would bet sooner or later you will need this, so I would go with #2. You will have to make more definitions though (multiple ReplyTo Aliases on QM1/QM2 instead of a single pair of Queue Manager Alaises on QM3). Big deal, the design will be better positioned for the future.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JT |
| Posted: Wed Aug 11, 2004 8:56 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Peter,
Our host MQSeries support team implemented option #1 and the message routing was successful between the clustered queue managers. Will be attempting option #2 later today/tomorrow and will let you know the results of setting the RQMNAME to blanks.
Many thanks for the suggestions!! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 11, 2004 1:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| Quote: |
Will be attempting option #2 later today/tomorrow and will let you know the results of setting the RQMNAME to blanks.
|
Make sure they get rid of Option #1 before you test Option #2.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
