| Author |
Message
|
| KIT_INC |
 Posted: Mon Aug 17, 2015 9:40 am Post subject: Alternate Message path in a cluster environment |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am running MQ 701 on windows
I have a test cluster (C1) of 4 Qmgrs (R1,R2,QM1,QM2), R1 and R2 are repository Qmgrs. A queue T1 is defined on QM2 only and shared in C1 cluster.
RUNMQSC QM2
DEF QL(T1) CLUSTER(C1) DEFBIND(NOTFIXED).
Use DIS QC(T1) on all 4 Qmgrs sees the Q as the cluster Q defined on QM2.
I can put a message to T1 from QM1 with no problem.
Someone ,by mistake, stop the cluster sender channel between QM1 and QM2. messages put from QM1 to T1 are now sitting in SCTQ of QM1.
I know that SDR channel from QM1 to QM2 is the shortest path to T1. But there are alternate paths available to T1 (via C1 or C2). All other Cluster SDR channels between Qmgrs are running. I was hoping that the cluster logic is smart enough to use the alternates. Will cluster try the alternate path or am I asking for too much ? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Aug 17, 2015 9:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I believe it will only use alternate paths if there's more than one cluster object. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 17, 2015 10:32 am Post subject: Re: Alternate Message path in a cluster environment |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| I was hoping that the cluster logic is smart enough to use the alternates. Will cluster try the alternate path or am I asking for too much ? |
You're asking too much. The cluster workload algorithm is used to work out which instance of a cluster queue a message will go to; in your case 100% of the messages will go to the only instance of the queue (!).
As to how messages get from where they are to where they've been address, all message traffic within a cluster is point to point between the 2 PRs via the auto-defined channels. So there are no "alternate paths" in a cluster.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 17, 2015 10:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| I believe it will only use alternate paths if there's more than one cluster object. |
If there are (for example) 2 instances of T1 in the cluster, messages will be addressed 50/50 between them. If the channel to one instance is stopped, after a period of time described by the configuration and explained in the documentation, one instance will become invalid as a target and all messages will go to the other.
Messages addressed to the downed instance but not transmitted before the channel stopped will sit on the SCTQ until the channel restarts.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Mon Aug 17, 2015 10:39 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Thanks a lot for the confirmation. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 17, 2015 10:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| Thanks a lot for the confirmation. |
Don't forget that in later versions of MQ, messages do not sit on the SCTQ but can be configured to sit on one of the SCTQs. So if one of the channels stops, it's easier to detect which one.
(I couldn't help noticing that your version of MQ is EOS in a month, and thought I'd offer a fish you can throw at management to smooth the upgrade path).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 17, 2015 10:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Also, don't forget BIND_NOT_FIXED |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 17, 2015 10:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Also, don't forget BIND_NOT_FIXED |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Tue Aug 18, 2015 8:49 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Thanks Vitor, We will be V8 in Oct. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 18, 2015 9:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| KIT_INC wrote: |
| Thanks Vitor, We will be V8 in Oct. |
See "Monitoring" here as a starting point 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| H.E.W. |
| Posted: Wed Aug 26, 2015 5:37 am Post subject: |
|
|
Newbie
Joined: 26 Aug 2015
Posts: 1
|
Hi KIT_INC,
you could try the following:
Define an ALIAS-Q on QM1 named T1_ALIAS and shared it in C1 Cluster.
Set the Base-Object-Name to T1.
ALTER T1 on QM1 CLWL-Priority to 5.
Define an ALIAS-Q on R1 and R2 named T1 and shared it in C1 Cluster.
Set the Base-Object-Name to T1_ALIAS and CLWL-Priority to 0.
If everything is up and running, Messages from QM2 should directly flow to T1 on QM1.
If the cluster sender channel between QM1 and QM2 is stopped, the Messages are routed to Queue T1 on R1 or R2 and then to Queue T1-ALIAS on QM1 (this is your T1-Queue) |
|
| Back to top |
|
|
|
|
