| Author |
Message
|
| Mr Butcher |
 Posted: Thu Jul 21, 2005 6:09 am Post subject: |
 |
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
just some guesses (because you talked about a queue with a persistent message).
how about a namelist? no need to backout here.
how about a qalias (same name everywhere) but pointing to a different qlocal, the name of the qlocal should be returned by the mqopen in the resolvedname of the mqod. no need to read a message here, just open something to get your name.
how about mqinquire for a specific object? if exist, its our name.
i am sure there are some more like these....
_________________
Regards, Butcher |
|
| Back to top |
|
 |
| wschutz |
| Posted: Thu Jul 21, 2005 6:44 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| 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? |
No, they do not.
What about setting an environment variable and then using "IA06: WBI Message Broker - Get all environment variables".
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 21, 2005 6:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| wschutz wrote: |
| What about setting an environment variable and then using "IA06: WBI Message Broker - Get all environment variables". |
| jefflowrey wrote: |
| 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 |
|
|
| PeterPotkay |
| Posted: Thu Jul 21, 2005 2:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
I will check out that support pack.
The ReplyToQ Aliases will work also, but means more q defs. Oh well.
I should have named the clusters the same between DEV, QA and PROD, so the WB-IMB flows could have hardcoded it. Well, maybe not, it would seem weird to have them all named the same, but I guess there is no techincal reason not to. Probably a little safer to keep the names different - one extra thing that needs to be set just so, to make it a little less likely of a QM joining the wrong cluster by user error.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 21, 2005 6:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
Guys you are all so complicated in your alias definitions.
I assume that the sending party will know what cluster it is in.
a) the sending party uses the attributes of the queue to retrieve the namelist or cluster
b) the sending party creates a fictional JMS destination and puts it to the reply to queue
or
Just define the damn reply to queue as lookup in JNDI. Does not need to exist and can be accessed through alias routing...
Say I am on qmgr QM1 in cluster CL3...
My reply to queue name is QMX REPLY. (this would be the broker queue ?)
I have either set my JMS Destination to "queue://CL3/REPLY" or retrieved a queue with this information from properties/jndi / other config means for the app.
I need one alias throughout the cluster:
def qr(CL1) rqmname(' ') cluster(cl3)
And that's it. !!
Load balancing included...
 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 21, 2005 9:13 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
The replying app cannot have a predefined JMS destination, or a predefined remote queue def pointing back at the reply q inside the cluster. That defeats the whole point of this.
The replying app simply replies to the MQMD's Reply2Q and Reply2QM of the incoming request message. That request message could be coming from anywhere, so there is no way to predefine queues, JNDI or otherwise. The replying app is properly written and designed to respect the MQMD's Report options, Reply2Q and Reply2QM. In the case where that request message is from a Broker from inside the MQ cluster, we need the ReplyToQM to be the cluster name on that request message.
The Broker must send a request message with a properly addressed Reply2Q and Reply2QM in the header, where the Reply2QM is the cluster name.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jul 22, 2005 5:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Jeff, IA09 is a Category 2 Support Pack 
If we ignore that fact, and decide to use it, it says it gets all the env variables. So I would just create a new Environment Variable called CLUSTERNAME, and set it appropriatly on each Broker server?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jul 22, 2005 5:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
What if on every QM outside of the cluster, I create a QMAlias like this:
| Code: |
DEFINE QREMOTE(FASTCLUSTER) RNAME() RQMNAME(ActualClusterNameHereDependingOnIfItsDEVorQAorPROD) XMITQ(ToTheGatewayQM).
DEFINE QREMOTE(NORMALCLUSTER) RNAME() RQMNAME(ActualClusterNameHereDependingOnIfItsDEVorQAorPROD) XMITQ(ToTheGatewayQM)
|
On the Gateway, I do this:
| Code: |
DEFINE QREMOTE(FASTCLUSTER) RNAME() RQMNAME() XMITQ().
DEFINE QREMOTE(NORMALCLUSTER) RNAME() RQMNAME() XMITQ()
|
Then the WB-IMB flows that want this behaviour hard code FASTCLUSTER or NORMALCLUSTER as the ReplyToQM on the outgoing Request message. The Replier will pick it up, and send it back to REPLYQ at FASTCLUSTER. The message finds its way back to the GW, where the QMALias there wipes the FASTCLUSTER or NORMALCLUSTER clean, and the message is free to round robin. That will work!
Benefits:
The flow's ESQL does not need to change between DEV, QA or PROD.
I do not need to rely on a Cat 2 Support Pack
I do not need to make 100s of ReplyTo Aliases for every Reply Queue.
If the flow is such that it needs the reply to come back to the specific Broker, nothing interferes with the flow allowing the MQMD_ReplyToQM to default to the local Broker QM name.
I like it!
Any drawbacks that people can see?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 22, 2005 5:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| Jeff, IA06 is a Category 2 Support Pack |
Well. Yes....
| PeterPotkay wrote: |
| If we ignore that fact |
There isn't a category 3 support pack that will do anything like what you need.
The only feature "out of the box" that could be adopted would be a database table. And that might get a little complicated, as you'd essentially have to set up a different table for each environment, and figure out how to reference the different tables from a common name.
The choices then are to write a custom plug-in, and have to support it, or use an IBM supplied (if not supported) plug-in, and have to support that.
Or try to figure out how to solve your problem without this sort of environmental dependancy.
| PeterPotkay wrote: |
| , and decide to use it, it says it gets all the env variables. So I would just create a new Environment Variable called CLUSTERNAME, and set it appropriatly on each Broker server? |
Yep. And then in your esql access Environment.ENV.CLUSTERNAME or wherever this puts them. This could even be set for different brokers on each server - by tweaking the startup of each broker to set a specific environment variable for each (this gets a little harder on Windows if you're using the Broker as a service... but not TOO much harder).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Jul 22, 2005 5:52 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
So you're thinking that this definition:
| Quote: |
DEFINE QREMOTE(FASTCLUSTER) RNAME() RQMNAME() XMITQ().
DEFINE QREMOTE(NORMALCLUSTER) RNAME() RQMNAME() XMITQ() |
Is equivaluent to:
| Code: |
DEFINE QREMOTE(FASTCLUSTER) RNAME() RQMNAME(thisGWQmgr) XMITQ().
DEFINE QREMOTE(NORMALCLUSTER) RNAME() RQMNAME(thisGWQmgr) XMITQ()
|
Right?
_________________
-wayne |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jul 22, 2005 7:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| wschutz wrote: |
So you're thinking that this definition:
| Quote: |
DEFINE QREMOTE(FASTCLUSTER) RNAME() RQMNAME() XMITQ().
DEFINE QREMOTE(NORMALCLUSTER) RNAME() RQMNAME() XMITQ() |
Is equivaluent to:
| Code: |
DEFINE QREMOTE(FASTCLUSTER) RNAME() RQMNAME(thisGWQmgr) XMITQ().
DEFINE QREMOTE(NORMALCLUSTER) RNAME() RQMNAME(thisGWQmgr) XMITQ()
|
Right? |
No.
My second set of definitions (quoted above) are only on the Gateway QM, and exists to specifically wipe out any destination QM from the incoming message, leaving it free to round robin into the cluster.
Your definition (quoted above) would grab any message with a destination QM of FASTCLUSTER or NORMALCLUSTER, and force it to look for the q on the GW QM only, which would then cause it to go to the DLQ, because the GW does not have any clustered app queues.
I think using these QM Aliases is the way we will do it. After the grief we had with the MQGET node, I don't want to rely on a Cat 2 Support Pack again. Hopefully WB-IMB 6.0 will allow a flow to easily, effeciently and officially determine what Broker it is on, and/or access Namelist easily, effeciently and officially.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
