| Author |
Message
|
| balaji83it |
 Posted: Mon Oct 04, 2010 10:43 pm Post subject: |
 |
|
Acolyte
Joined: 20 Jul 2007
Posts: 72
|
| Try creating a new Execution group and deploy there. |
|
| Back to top |
|
 |
| sheetalur |
| Posted: Tue Oct 05, 2010 5:36 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2010
Posts: 9
|
| balaji83it wrote: |
| Try creating a new Execution group and deploy there. |
Already did that. It gives the same timeout exception in the event log. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 05, 2010 5:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sheetalur wrote: |
| balaji83it wrote: |
| Try creating a new Execution group and deploy there. |
Already did that. It gives the same timeout exception in the event log. |
While trying that, did you find any answers to my earlier questions? Further help is unlikely without those.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sheetalur |
| Posted: Tue Oct 05, 2010 6:58 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2010
Posts: 9
|
| Vitor wrote: |
So does the Configuration Manager show the broker as running within the topology? |
I can see the broker is running as a service( from Control Panel) and it does show up under the configuration manager in the domain view of the MBT. Any other way to check if the broker is running within the topology?
| Vitor wrote: |
And what success messages? That the services have started? Are there any error messages in the Event Viewer connected to the deploy? |
Yes, the success messages tell that the services have started.
Following is the message in the event Viewer for the deployment.
BIP2066E: Broker WBRK6_DEFAULT_BROKER (UUID 97ec5953-2b01-0000-0080-f6a2a4f4f564) was unable to retrieve an internal configuration response message for execution group 'default' within the 360 second Configuration Timeout.
The execution group did not respond within the Configuration Timeout period. A negative response is returned to the Configuration Manager for this execution group. The Configuration Timeout is the maximum length of time that an execution group is allowed to apply a deployed configuration change. By default the Configuration Timeout period is 300 seconds. You can increase (or decrease) the timeout by using the mqsichangebroker option, ConfigurationTimeout. This will not resolve any underlying problem with the deployed message, but can be used to reduce the response turnaround time or increase it to allow for large and complex deployments.
Investigate why the execution group was unable to respond before being timed out. Use the system log messages to determine if there is a problem with the execution group. You should check that your system is not running short of resources, for example, you may need to increase the WebSphere log size. Reducing the complexity of the deploy by reducing the number of execution groups may also help to alleviate this problem. Correct the problem and redeploy the broker's configuration from the Message Brokers Toolkit, mqsideploy command or Config Manager Proxy. If there are no other failure diagnostics then you should consider increasing the Configuration Timeout, increase this value in units of 300 until this message no longer occurs. Contact your IBM support center if you are unable to resolve the problem. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 05, 2010 7:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sheetalur wrote: |
| Vitor wrote: |
So does the Configuration Manager show the broker as running within the topology? |
I can see the broker is running as a service( from Control Panel) and it does show up under the configuration manager in the domain view of the MBT. Any other way to check if the broker is running within the topology? |
No, that sounds fine.
| sheetalur wrote: |
| Investigate why the execution group was unable to respond before being timed out. Use the system log messages to determine if there is a problem with the execution group. |
I think this is your next port of call. I'm guessing your flow is not especially complex?
You should also re-check that communication is happening normally between CM qmgr & BK qmgr. Also there are no dbase errors at or about the time of the deploy. As well as the steps above.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sheetalur |
| Posted: Tue Oct 05, 2010 7:24 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2010
Posts: 9
|
| Vitor wrote: |
I'm guessing your flow is not especially complex?
|
It is just a MQInput node and a MQOutput node.
| Vitor wrote: |
re-check that communication is happening normally between CM qmgr & BK qmgr
|
How do I check the flow between them? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 05, 2010 7:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sheetalur wrote: |
| How do I check the flow between them? |
WMQ 101 - all the normal things. Queues, channels, all that good stuff. It's just 2 applications talking, don't be thrown by both the apps being IBM software.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 05, 2010 7:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Open up an MQSI Command Console.
Issue mqsistart for both the broker and the configmgr.
If they both return that the component is already started, then more investigation is needed.
If one of them returns that it has started a component, then likely bob is now your uncle.
You appear to be using the Default configuration. The default configuration will assign both the broker and the ConfigMgr to the same queue manager, such that there is no communication checking needed, as they are in the same place.
The error you have shown suggests that the Broker is running and the EG is unresponsive. Therefore, you should mqsistop -i the Broker, to cause it to kill the EG process. Then mqsistart it again and retry the deploy.
Edited To Add: the MOST LIKELY cause of the EG being unresponsive is that you have left yourself connected to it in a debug session.
The second most likely cause is that you have coded an infinite loop in your message flow. |
|
| Back to top |
|
|
| sheetalur |
| Posted: Fri Oct 22, 2010 5:48 am Post subject: |
|
|
Newbie
Joined: 27 Sep 2010
Posts: 9
|
Thanks all for your responses!
I had got sidetracked with a couple of other issues in the project( not MQ related). I am now waiting to get a new version of Broker and Server from our MQ admin, hopefully installing the latest components will resolve the issue. |
|
| Back to top |
|
|
|
|
