Author |
Message
|
ananthas |
Posted: Thu Mar 18, 2004 4:01 pm Post subject: Cluster failover not working |
|
|
Newbie
Joined: 16 Oct 2001 Posts: 4
|
All,
We have a cluster of queue managers QMF1, QMF2, QWN1 and QWN2 (MF-
Mainframe, WN- Windows) running on mainframe and windows. The QMF1
and QWN1 act as primary and secondary repository.
When QWN1 is up and running, messages are loadbalanced between the
queues in QWN1 and QWN2. But when QWN1 is down, (the cluster sender
channel TO.QWN1 from both QMF1 and QMF2 are also brought down) the
messages get stuck in the SYSTEM.CLUSTER.TRANSMIT.QUEUE in QWN2.
These messages move to QWN1 once it is brought up.
I don't understand why the messages don't go to QWN2 and get
processed there. Wondering what could be wrong?
Thanks, |
|
Back to top |
|
 |
offshore |
Posted: Fri Mar 19, 2004 10:08 am Post subject: |
|
|
 Master
Joined: 20 Jun 2002 Posts: 222
|
Anathas,
Your question is a litte bit confusing to me. What kind of messages are getting stuck in QWN2? Its sounds to me that your mainframe queue managers send messages to QWN1 & QWN2 for processing.
So if anything when QWN1 was brought down MQ messages from the mainframe could possibly stay on their SYSTEM.CLUSTER.TRANSMIT.QUEUE if they are told to goto QWN1.
The only type of message from QWN2 that I can see sitting on the SYSTEM.CLUSTER.TRANSMIT.QUEUE is repository information it wants from QWN1 <which is offline and not part of the cluster>.
Do you know if they're messages that an application is putting or they repsoitory sync messages placed there by the MQ subsystem?
I need some more info. I have some ideas depending on your answer.
Offshore |
|
Back to top |
|
 |
ananthas |
Posted: Mon Apr 05, 2004 7:18 am Post subject: More details |
|
|
Newbie
Joined: 16 Oct 2001 Posts: 4
|
Sorry for the delay in response. Never got a notification from the forum.
Yes all the messages in SYSTEM.CLUSTER.TRANSMIT.QUEUE of QWN2 were application messages. These messages went to QWN1 once QWN1 was brought up and got processed from there.
In daily scenario, when QWN1 is up, the messages get round-robined to both the queue managers. |
|
Back to top |
|
 |
JasonE |
Posted: Mon Apr 05, 2004 7:22 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
Do your apps use bind on open or bind not fixed (or bind as q def, and in which case what is the default bind option on the queue in question (DEFBIND)) |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Apr 05, 2004 7:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
As Jason said, in a message he snuck in while I was typing a reply, if your applications are using BIND_ON_OPEN instead of BIND_NOT_FIXED, then they will continue directing messages to QWN1 even when QWN1 is down.
And please remember that MQSeries clustering is not failover. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
ananthas |
Posted: Mon Apr 05, 2004 8:09 am Post subject: |
|
|
Newbie
Joined: 16 Oct 2001 Posts: 4
|
Even if the messages are directed towards QWN1, I am unsure why they were stuck in CLUSTER TRANSMIT queue at QMF1 or QMF2 (from where the messages are originated) rather than that of QWN1.
Also on a regular day the messages go to both the queue managers (QWN1 and QWN2). But during this incident, none of the messages went to QWN2 till QWN1 was brought up. |
|
Back to top |
|
 |
vennela |
Posted: Mon Apr 05, 2004 8:16 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
By the time messages are put in the CLUSTER TRANSMISSION queue, their destination is determined. Once the message is in the transmission queue and it is destined to QWN1, and if the CLUSSDR to QWN1 is down, these messages will stay on the transmission queue and they will NOT go to QWN2. |
|
Back to top |
|
 |
JasonE |
Posted: Mon Apr 05, 2004 8:49 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
I dont believe that is entirely true.
IF the messages were not put with bind on open, then I think the messages can be moved even while they are on the transmit queue for when a channel fails (goes into retry - not sure about stopped but I'd assume that is true as well). |
|
Back to top |
|
 |
vennela |
Posted: Mon Apr 05, 2004 9:00 am Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
|
Back to top |
|
 |
JasonE |
Posted: Mon Apr 05, 2004 10:24 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003 Posts: 1220 Location: Hursley
|
np - I didnt join until Nov last year!
I also remember there have been a couple of fixes in this area, so it worked in more scenarios. I can remember the routine which does it but cant remember all the reasons it gets called! |
|
Back to top |
|
 |
|