| Author |
Message
|
| hkhan12 |
 Posted: Tue Dec 11, 2007 4:26 am Post subject: QMGR SUSPEND NOT WORKING |
 |
|
Voyager
Joined: 08 Aug 2002
Posts: 98
|
Hi Guys,
I have following senarios:
2 Full Repository QMGRS (One on AIX and other one on Solaris)
1 Partial Repository on Windows and others are on AIX.
I have suspended my partial repository on Windows using MQExplorer v6.
I have also removed my cluster-receiver channel from cluster after I alter it - CLUSTER(' ') and than I deleted the cluster-reciever channel.
Everything looks good because I got proper messages saying my partial repository have been suspended from my cluster.
On my Full Repository AIX box, I found my partial repo qmgr still showing SUSPEND(NO) when I ran following command:
DIS CLUSQMGR(QMGR_NAME) SUSPEND. It is showing as
CLUSQMGR(EENT601I) CLUSTER(CLUSTER_NAME)
CHANNEL(EENT601I.C) SUSPEND(NO)
I have also did RESET CLUSTER with forceremove option on my AIX repository queue manager.
When I start testing between other queue managers in my cluster,
I'm getting the following error messages.
12/11/07 08:06:02 - Process(21517.8 User(mqm) Program(amqrmppa)
AMQ9202: Remote host 'kin52u4d (99.9.99.99) (9999)' not available, retry
later.
EXPLANATION:
The attempt to allocate a conversation using TCP/IP to host 'kin52u4d
(99.9.99.99) (9999)' was not successful. However the error may be a transitory one and it may be possible to successfully allocate a TCP/IP conversation later.
ACTION:
Try the connection again later. If the failure persists, record the error
values and contact your systems administrator. The return code from TCP/IP is 146 (X'92'). The reason for the failure may be that this host cannot reach the destination host. It may also be possible that the listening program at host 'kin52u4d (99.9.99.99) (9999)' was not running. If this is the case, perform the relevant operations to start the TCP/IP listening program, and try again.
----- amqccita.c : 1182 -------------------------------------------------------
Any help or input would be highly appreciated!!!
Thanx..... |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Dec 11, 2007 10:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
Well changes to a cluster usually take some time to propagate.
You can force propagation by using refresh cluster(myclustername) on an FR and refresh cluster(myclustername) repos(yes) on a PR.
BTW I would verify on the FR that my PR is suspended before I use any more drastic measures...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Dec 11, 2007 2:41 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
I am a little surprised that fjb should recommend REFRESH CLUSTER so glibly.
In the situation above, there is clearly some sort of comms error between machines hosting cluster qmgrs. Issuing REFRESH CLUSTER while the cluster qmgrs are not capable of communicating is probably the easiest way to lose all the cluster metadata, guaranteeing future cluster problems.
Sort out the comms FIRST, then you will probablyt find that the cluster data will be available shortly afterwards without needing to issue any commands at all.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 11, 2007 2:41 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
REFRESH CLUSTER, as clearly stated in the documentation, is disruptive to the cluster, and should only be used in extraordinary circumstances.
You should have unshared all objects from the cluster first before removing the channel, and then suspend the qmgr and then alter it to remove if from the cluster, and then stop all cluster channels to & from the qmgr, and then delete the cluster channels.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 11, 2007 9:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| jefflowrey wrote: |
REFRESH CLUSTER, as clearly stated in the documentation, is disruptive to the cluster, and should only be used in extraordinary circumstances.
You should have unshared all objects from the cluster first before removing the channel, and then suspend the qmgr and then alter it to remove if from the cluster, and then stop all cluster channels to & from the qmgr, and then delete the cluster channels. |
Yes it is disruptive. However I have seen it to be the fastest way for a PR to quickly reacquire the needed cluster information and force a flush of the cache... And you are right. You should never use it (refresh cluster) if you have a communications problem... .
If you do it will make things worse until the communications problem is fixed
So First make sure following channels are working and in status=running:
the PR to the FR
FR to all other FRs
FR to PR and PR to FR on the PR you see the problem...
And remember : even though the channel is autodefined you can still start it manually using start chl(to.destqmgr)
If this does not fix it, I have been known to use the refresh cluster.
The stutter it provoked (with good communications) on the PR was less than 3 seconds...
By experience most propagation of "needed information" that took more than 10 seconds (subjective sitting and waiting for the change) were due to channel problems ( channel in long retry after maintenance for a few hours) and can be fixed by manually restarting a few channels.. on the PR and it's associated primary FR
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Dec 12, 2007 11:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Refresh Cluster can take a significant amount of time to complete, depending on whether you have stopped the cluster channels first.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 12, 2007 4:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| jefflowrey wrote: |
| Refresh Cluster can take a significant amount of time to complete, depending on whether you have stopped the cluster channels first. |
| fjb_saper wrote: |
| You should never use it (refresh cluster) if you have a communications problem |
In my book a stopped cluster channel qualifies as a communications problem.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Dec 13, 2007 5:32 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
fjb_saper,
I think Jeff meant stopped in the inactive state. I believe that if the channel is running when you issue the CLUSTER REFRESH, it will not complete until the channel stops and starts again. I'm sure I read this on another thread here just a few days ago but I don't seem to be able to find it.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
|
|
