| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Queue containing deployment info |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQGuy2000 |
 Posted: Tue Jan 27, 2004 10:39 am Post subject: Queue containing deployment info |
 |
|
Centurion
Joined: 20 Jul 2003
Posts: 131
|
Hi All,
I have a question reg. MQSI deployments.
- There are some incomplete / unsucessful deployments in my MQSI environment.
When ever I try to deploy all the brokers it gives me an error message.
Which queue has the information about scheduled deployments? can I remove the unwanted deplyments from the queue?
regards |
|
| Back to top |
|
 |
| mverh |
| Posted: Tue Jan 27, 2004 12:10 pm Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
A simple way to clear outstanding deploys is to delete the appropriate entries in the config mgr d/b. To see the outstanding deploys use the following sql:
select * from cbroker where csection = 'DPLING'
to get rid of outstanding deploys that you know are never going to respond use the following sql:
delete from cbroker where csection = 'DPLING'
Note, ideally you should determine why the deploy has failed to respond appropriately. This is just a last resort technique.
_________________
Marc Verhiel
IBM Canada Ltd. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 27, 2004 12:39 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I would rather troubleshoot the likely issues with either the MQ connection between the ConfigMgr and the broker, or whatever is causing the broker or execution group to loop - and therefore fail to respond to deployments. Changing the ConfigMgr database so that it thinks that a message flow is no longer being deployed isn't going to help if the broker won't accept any deployments.
First check for outstanding messages in your channels or in your SYSTEM.BROKER.* queues (all the queues that WMQI uses, and what they're for are listed in the Administration Guide or the Installation and Planning Guide). If there are none, and the channels appear to be working (or your broker shares a QM with your ConfigMgr), then your execution group/broker is not responding to deployments for some reason, and will need to be restarted.
If you can't get your broker to stop successfully with an mqsistop <broker>, you'll need to take more drastic measures. You can use mqsilist <broker> to get a list of the PIDS for each execution group process. See if these processes are looping - mainly by checking their CPU utilization. If one of them is looping, then it won't respond to a deployment. Kill the execution group process, and immediately issue and mqsistop <broker>. Or better yet, issue an mqsistop <broker> in one shell, and kill the EG in another.
Now look for unprocessed messages on your Input queues for your message flows - or for messages that may have been rolled back. That will help tell you which message flow is looping. Or you could enable tracing, and restart the broker. But until you can fix the looping, you won't be able to redeploy very well. If you're trying to deploy a fix for a looping problem... then GET disable the input queue, and then start the broker/eg and do a deploy.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mverh |
| Posted: Tue Jan 27, 2004 2:02 pm Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
Jeff, I agree that trying to determine why the deploy has not responded is the first thing you would want to do, but, in the case where the deploy message is nowhere to be found and as a result the config mgr never gets a response to the deploy, you have two choices:
1) force deploy
2) purge appropriate cbroker DPLING record and reattempt delta deploy
Using option 1 is ok if you have a small configuration but once you get multiple brokers with many flows and large message sets it quickly becomes virtually unworkable (ever had to bounce your configMgr due to resource problems, i.e. huge memory usage, and the configMgr continually rejects a deploy?) so you sometimes have no other option other than 2.
One scenario where I've seen deployment messages "lost" was our xmitq from the configMgr to the broker was defined as DEFPSIST(NO) and the channel NPMSPEED(FAST) and we had a network blip.
In a perfect world we will always get a response but this is not the case in the real world. Knowing how to manage the cbroker table is very helpful and should only be used as a last resort.
_________________
Marc Verhiel
IBM Canada Ltd. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
