| Author |
Message
|
| PeterPotkay |
 Posted: Wed Jul 20, 2005 1:05 pm Post subject: What cluster am I in? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
With 2 or more brokers in the same MQ cluster, I would like to have the outgoing Request flow produce a message whose Reply To QM field contains the name of the MQ Cluster, so that when the reply message comes back, it can go to any of my brokers, and not be obligated to going back to the Broker that processed the request.
Since the Cluster names change between LAB, DEV, QA and PROD, I need a way for the flow to find out what environment it is in, so that it can dynamically set the MQMD_ReplyToQManager field to the proper cluster name depending on what environment it is in.
Any ideas?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jul 20, 2005 1:08 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, you don't have overlapping clusters, then?
The only way to tell would be to check the cluster attributes of the Reply To Q - and the only way to do that is from something other than ESQL.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 20, 2005 1:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I do have stacked cluster, a FAST one and a NORMAL one. The flow would have the sense to know whther is needed to be FAST or NORMAL, because that would be the same whether it was DEV or QA or PROD. Now I need a way to figure out am I running in DEV or QA or PROD.
If I could find out what Broker I am running on, logic could easily be added that would deduce the cluster name from that, due to our naming standards (i.e. if the Broker name / QM name ends with a "P", it is PROD, "Q" is QA, etc).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Jul 20, 2005 2:09 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
apparently I do not understand something here - why not simply specify a cluster queue that is on both brokers in the ReplyToQ param?
This way the requester asks request with ReplyToQ=REP which is a cluster queue with two instances, one at each broker QM. Next the responder will put to REP, and b sent to either one of the brokers...? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 20, 2005 3:54 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Because by default the message will have the local QM's name in the MQMD_ReplyToQManager field. The replying app will be a good little app and will put its reply to the Reply2Q and the Reply2QM. I want that Reply2QM to be the cluster name, and not a particular broker.
That replying app may be in the same cluster, or 99% of the time, it may be on a QM outside of the cluster. In those cases, I need the request message to arrive with the Reply2QM set to the proper CLUSTER name. When the replier puts the reply to (ReplyQ on CLUSTERxyz), my QM Aliases will catch it and forward it on to the Gateway QM, who will round robin the replies to all available Brokers, and not be restricted to the one that produced the request.
So the request flow must override the default behaviour, and manually populate the MQMD_Reply2QM with the Cluster name. The trick is to figure that out dynamically in the code.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jul 20, 2005 4:09 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| If I could find out what Broker I am running on, |
Again, not from within ESQL.
Someone posted a sample plug-in a few months ago.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Jul 20, 2005 4:39 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Peter...does this help:
| Quote: |
Reply-to queue aliases
A reply-to queue alias definition is used to specify alternative names for reply information. Reply-to queue alias definitions can be used in conjunction with clusters just the same as in a distributed queuing environment. For example:
* Queue manager VENICE sends a message to queue manager PISA using the MQPUT call and specifying the following in the message descriptor:
ReplyToQ='QUEUE'
ReplyToQMgr=''
* So that replies sent to QUEUE can be received on OTHERQ at PISA, create a reply-to queue alias definition on VENICE:
DEFINE QREMOTE(QUEUE) RNAME(OTHERQ) RQMNAME(PISA)
This form of remote-queue definition creates a reply-to alias. This alias is effective only on the system on which it was created.
RQMNAME and QREMOTE can specify the same names, even if RQMNAME is itself a cluster queue manager.
See the WebSphere MQ Intercommunication book for more information. |
I would think you'd make this definition at each qmgr that hosts a broker and make the rqmname your cluster name.
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 20, 2005 6:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jeff,
I found this post:
http://www.mqseries.net/phpBB/viewtopic.php?t=8349&highlight=broker+name
Does not look promising.
I'm gonna open up a ticket with IBM and see what they officially say. If no easy way, I'll open up a requirement. I can't be the only one that needs this. Really, the solution would be if a flow could open up a Namelist. We talked about that before, here's another use for it.
Wayne, I though of the ReplyTo Alias route, but that will get..."busy"???
BROKERA and BROKERB are in CLUSTER1. REPLYQ is the real reply q.
I would have to define this:
| Code: |
DEFINE QREMOTE(REPLYQ.ALIAS) RNAME(REPLYQ) RQMNAME(CLUSTER1)
|
And then the flow would specify REPLYQ.ALIAS for the MQMD.ReplyToQueue. When the message left, it would be tagged in the MQMD with ReplyToQueue = REPLYQ and ReplyToQueueManager = CLUSTER. Cool.
Hmmmm, yeah, I guess that will work. All it means is for every reply queue on my brokers, I would then have to create a replyto alias. (That's alot of queues, but what the hay) If the flow wants the reply to come back to the cluster, it sets the reply to queue to REPLY.ALIAS, and if it wants it to come back to the specific broker, then it just codes the actual reply queue (REPLYQ) in that field.
Man, I wish there was a better way. Someone at work suggested creating a queue on each Broker called WHO.AM.I, and putting a persistent message with unlimited Expiry that would contain pertinent info, like the broker name. Any flow that wanted to know the info would use the MQGET node to open that queue, and get the message. Then they would have to roll it back, or put a copy of it back on the queue.  Probably would perform like a dog, and if the message gets eaten for good and not replaced, we are sunk.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Jul 20, 2005 11:34 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| You could populate the ReplyToQMgr field with a qmgr alias which has a blank RQMNAME. The reply would then be routed to any qmgr which knows about the ReplyToQ using the usual cluster techniques. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 3:15 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I really remember a post where someone actually put out code for a plugin.
I'll search some more later.
Also, IA06
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Maximreality |
| Posted: Thu Jul 21, 2005 4:21 am Post subject: |
|
|
Acolyte
Joined: 04 Jun 2004
Posts: 65
Location: Copenhagen
|
| jefflowrey wrote: |
| PeterPotkay wrote: |
| If I could find out what Broker I am running on, |
Again, not from within ESQL.
Someone posted a sample plug-in a few months ago. |
.....you could make an external Java call from within the flow and then get the actual broker name.
Create a new MbNode object in, from that object get the broker instance that the node is created on and then get the name from that object.
| Code: |
package com.ibm.broker;
import com.ibm.broker.plugin.*;
public class Utils {
/*
* Returns the name of the broker, which the flow is running on.
*/
public static String getBrokerName() {
String value = "error";
try {
MbNode mn = new MbNode();
MbBroker mb = mn.getBroker();
value = mb.getName();
} catch (MbException e) {
return value;
}
return value;
}
} |
This what the ESQL procedure could look like.
| Code: |
CREATE PROCEDURE getBroker ()
RETURNS CHAR
LANGUAGE JAVA
EXTERNAL NAME "com.ibm.broker.Utils.getBrokername"; |
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 4:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Maximreality wrote: |
| .....you could make an external Java call from within the flow and then get the actual broker name. |
If you read the post that Peter linked to, you will see that this isn't workable.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 21, 2005 5:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Nigelg wrote: |
| You could populate the ReplyToQMgr field with a qmgr alias which has a blank RQMNAME. The reply would then be routed to any qmgr which knows about the ReplyToQ using the usual cluster techniques. |
I can't have a blank ReplyToQM, because 99% of the requests leave the cluster, and the replier is outside of the cluster, so they need the cluster name in the ReplyToQM field.
BUT, what if I create a QMAlias called CLUSTERFAST like so:
| Code: |
DEFINE QREMOTE(CLUSTERFAST) RNAME() RQMNAME(ActualFastClusterNameHere) XMITQ()
|
| Code: |
DEFINE QREMOTE(CLUSTERREG) RNAME() RQMNAME(ActualRegularClusterNameHere) XMITQ()
|
Now if a flow wants the reply to come back to the specific Broker that processed it, it just fills the Reply2Q and lets the Reply2QM default to the local QM. But if it wants the reply to come back to the fast cluster, it populates the Reply2QM field with CLUSTERFAST, and the Reply2QM value would be changed to the actual cluster name, which I will insure is correct through the various environments.
Now that I think of it, is that even going to work? I never read that QM Aliases will alter a value inside the MQMD_ReplyToQM. Do they?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 5:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
Now that I think of it, is that even going to work? I never read that QM Aliases will alter a value inside the MQMD_ReplyToQM. Do they? |
I don't know.
I'll repeat my recommendation for using IA06 to populate a field you can access with ESQL, though. It might have gotten lost in the shuffle.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Jul 21, 2005 6:01 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
Peter,
from what i read in the manual (application programmers reference, mqod, replytoq and replytoqmgr) it will not work.
only if the replytoqmgrname is blank, mq will look for a local defined remotequeue with the same name as the specified replytoqueue, and - if found - it will use the remoteqmgr name from that definition to replace the blank replytoqmgr.
if you specify a value, mq will not look up for a local remoteq definition....
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
