| Author |
Message
|
| sfari |
 Posted: Wed Aug 10, 2005 6:12 am Post subject: Suspend Queue Manager |
 |
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Hi, In our Solaris, z/OS Cluster each queue manager needs to be stopped once a day for doing a backup. On Solaris our QMs suspend from the cluster before they stop. On z/OS they get stopped without beeing suspended.
I have read that suspending a queue manager for maintainance is a good idea. But it is not clear to me what could happen if we just stop a queue manager without suspendig it first.
Is there somebody able and willing to explain this?
Thanks a lot! |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Wed Aug 10, 2005 7:11 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
other queuemanagers may think that this queuemanager is still available to receive messages, and may send messages to this qmgr that can not be delivered and may be stuck indoubt in the system.cluster.transmit.queue
(maybe)
i am not sure if it is a good idea to suspend a fr before shutting down....
mhhh......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Aug 10, 2005 10:59 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
when you suspend a cluster qmgr, all shared queues are marked as unreachable in the repository. This means that if you do not suspended, msgs will go on being sent to it, and the repository will keep trying to reconnect to it. After a while, though, the repository will mark those q's as unreachable and all will be well.
No msgs would be indoubt, they will simply wait around in the SYSTEM.CLUSTER.TRANSMIT.QUEUE until the qmgr is up.
Still, I would definitely suspend the qmgr before hand; clusters are fragile beings, and may not take kindly to any careless handling... |
|
| Back to top |
|
|
| sfari |
| Posted: Mon Aug 15, 2005 11:47 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
| Hi, thanks for your answers! What woud you suggest should a cluster queue manager always be suspended before shutting it down? Or is it never a problem to shut it down without suspending? |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Aug 16, 2005 12:02 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| hopsala wrote: |
No msgs would be indoubt, they will simply wait around in the SYSTEM.CLUSTER.TRANSMIT.QUEUE until the qmgr is up.
|
I don't think this is true. From what I read earlier in this forum, the messages will be rerouted to the available cluster members.
| Quote: |
| Or is it never a problem to shut it down without suspending? |
AFAIK, that is not necessary. You can simply shutdown the QMGR. |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Aug 16, 2005 4:56 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
venella - apparently I did not explain myself well enough. What I meant is that between the time the qmgr is down and the time the cluster repository finds out about it, some msgs will be put to system.cluster.transmit.queue and wait there. Naturally once the cluster repository discovers that the qm is down (depends upon heartbit of cluschl) all msgs will only routed to the active qmgrs.
The q here is, once a msg is already in transmitq, is it not already marked for delivery for a specific qmgr? In my opinion it is, but admittadly this is something I haven't tested. If I remember correctly, msgs in transmitq are directed to proper qmgr according to corrlid of the msgs, each cluschl gets by corrlid of the remote qm.
What this means, if i'm correct, that msgs already put to transmitq are eternally stuck there until the qm that was available during put is up. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Tue Aug 16, 2005 5:18 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
When a channel comes out of its running state for whatever reason, the clusterworkload exit is re-invoked for that particular channel. Any messages that can be routed to a valid alternative in the cluster will be, however if the only instance of the cluster queue reside on the non-contactable queue manager they will stay in the transmit queue until that qm becomes available again and the channel is running.
Hope this helps
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Aug 16, 2005 5:20 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Msgs on the cluster xmitq are pinned to a particular qmgr if
1 The msgs were put BIND_ON_OPEN
2 There is only 1 possible destination in the cluster
3 The cluster channel is indoubt
Msgs are put through the cluster destination chooser to be reallocated to another qmgr in the cluster when the channel stops. Msgs which meet any of the above conditions are not reallocated. Note that msgs which are eligible to be reallocated may be put back to the same qmgr.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 16, 2005 5:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Nigelg wrote: |
| Note that msgs which are eligible to be reallocated may be put back to the same qmgr. |
This means that, since the channel has stopped, those messages that are reallocated to the same qmgr will sit on the transmit queue - until the next time something happens that cause the to be given back to the cluster destination chooser.
If I'm following what's been said.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Tue Aug 16, 2005 6:46 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Yes, the clusterworkload exit is called once the channel alters from its running state. It goes through the SYSTEM.CLUSTER.TRANSMIT.QUEUE to find all messages that are asigned to that channel. If the rules allow it to be sent to another cluster queue the header is altered accordingly and the message placed back on the transmit queue. If the message can only go to the original queue manager it is placed back on the transmit queue as is. Once this re-allocation completes the channel then goes back to its normal starting procedure. I think that the messages will stay there until the channel is running again and that no more re-allocating is done.[/quote]
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 16, 2005 6:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| KeeferG wrote: |
| no more re-allocating is done. |
That was my point.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Aug 16, 2005 2:05 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Wonderful, I stand corrected, you learn something new every day 
However, since I have once written a cluster workload exit, I know that it is usually called only once per msg before entering transmitq, so i'm wondering what are the exact conditions to having the exit going over the entire q?
for example, what happens in the following scenario:
1. There is only 1 available destination for Q1 on QM1
2. A prob occurs and QM1 becomes unavailable, however, the repository is still unaware of this.
3. Someone MQPUT's to Q1, and this goes to transmitq with QM1 in the header.
4. After a short while the chl to QM1 goes down, and, as you here suggested, the cluster workload exit is called for each msg in the transmitq. Naturally, they are placed back with QM1 in the header since there are no other available destinations.
5. After a little while the admin created another destination for Q1 at QM2 (or conversly, QM2 which was up until now unavailable, goes up)
So, is the cluster workload exit called again for the entire transmitq?
I have not been able to find an exact rule table - such as that found for triggering conditions, for example - that states when the workload exit is called for the entire q, has anyone come across such a table? |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Aug 16, 2005 10:52 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
A channel which ends because the remote qmgr is not available goes into RETRYING state, when it will start and stop every SHORTTMR seconds for SHORTRTY times, then every LONGTMR seconds for LONGRTY times.
Every time the channel starts and stops it will read all the msgs on the queue and reallocate each one if possible. If the qmgr has new information about an alternative destination in the cluster, the msgs will get reallocated to the new destination after a maximum of LONGTMR seconds, when the channel next tries to start.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
