Author |
Message
|
tkaravind |
Posted: Thu Aug 23, 2007 10:39 am Post subject: Cluster behaviour with CLUSSDR channels in STOPPED state ... |
|
|
Acolyte
Joined: 24 Jul 2001 Posts: 60
|
Hi All,
I encountered the following behaviour with WMQ clusters :
We have two queue managers QM1 & QM2 as part of the same cluster.
Q1 is defined on both and included in this cluster ( clones ).
It is defined with Default Bind "NOT FIXED".
Normally another qmgr : QM3 sends msgs to both QM1 & 2 in a round-robin basis which is as expected.
However during a recent activity we were forced to Suspend QM1 from cluster and also STOPPED the cluster sender TO.QM1 on QM3 so as to ensure msgs went only to QM2. But by mistake the Q1 on QM2 was removed from cluster.
This caused QM3 to still try and send msgs to QM1 ( as it was only suspended). But msgs were stuck on System cluster xmit Q as the cluster sdr TO.QM1 was stopped.
We later included Q1 on QM2 as part of the same cluster and expected QM3 to retry the msgs on its System cluster xmit Q and send to QM2 , now that Q1 on it was clustered....
However this did NOT happen. We had to manually move the messages across.
Is this a normal behaviour of qmgr cluster ? Or is it happening because TO.QM1 was stopped and msg retry would have been automatic if the same was in RETRY state ?
This has caused big confusion. Any further info is highly appreciated.
Many thanks in advance.
Aravind |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Aug 23, 2007 11:13 am Post subject: |
|
|
Guest
|
When you issue a STOP CHANNEL command, you must manually restart the channel. |
|
Back to top |
|
 |
tkaravind |
Posted: Thu Aug 23, 2007 11:18 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001 Posts: 60
|
True. But my question was regarding the cluster behaviour itself - that it should try its best to deliver to an alternate location ( in this case QM2) if it cannot see a way to QM1 ( if TO.QM1 is STOPPED) |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Aug 23, 2007 11:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Aug 23, 2007 11:29 am Post subject: |
|
|
Guest
|
Quote: |
Q1 is defined on both and included in this cluster ( clones ). It is defined with Default Bind "NOT FIXED". |
Which BIND_ option did the programmer specify in the application?program?
BIND_FIXED?
BIND_NOT_FIXED?
BIND_AS_Q_DEF? |
|
Back to top |
|
 |
tkaravind |
Posted: Fri Aug 24, 2007 1:53 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001 Posts: 60
|
Thanks Jeff. That link was very helpful.
However in this case how should one distinguish between a channel that has already failed and one that is "failing" ?
Can we assume that a channel that is in RETRY state is "failing" and STOPPED has already failed ? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Aug 24, 2007 4:52 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
that's my understanding.
If I'm going to stop a cluster channel to prevent messages from going to a QM, I stop the CLUSRCVR(s) on the QM I don't want anything going to. That way incoming channels are retrying, and messages stuck in the S.C.T.Q. get rerouted (unless they are hard coded to go to that one QM) _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
tkaravind |
Posted: Fri Aug 24, 2007 6:20 am Post subject: |
|
|
Acolyte
Joined: 24 Jul 2001 Posts: 60
|
Thanks Peter. Yes...Stopping the CLUSRVCR channel would have been easier and the right thing to do as well.
Carrying this a bit forward, if queues on both queue managers ( QM1 & QM2) are defined as part of cluster correctly and if the cluster channel to one (QM1) is STOPPED ( on QM3) :
Is the cluster logic by default good enough to see this and route all the msgs from QM3 through to the queue manager ( QM2) for which the cluster sender can actually RUN ?
Or does this depend on some cluster settings ? |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Aug 24, 2007 6:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Doesn't matter much if the messages have already gone through destination resolution. If the cluster found that the only viable destination queue is on QM1 the messages have been assigned to QM1 and will stay so.
Stopping the channel whether cluster receiver or sender will have little effect on existing messages once they have a destination qmgr assigned.
Now for NEWLY posted messages the algorythm should be able to determine the viable destinations and load balance between them.  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|