| Author |
Message
|
| atlas |
 Posted: Tue Jul 30, 2013 10:13 pm Post subject: Reg:Reducing the complicity of the Execution Group |
 |
|
Newbie
Joined: 03 Jul 2013
Posts: 6
|
Hi to all
I need some help that can any one please tell me how to reduce the complicity of the Execution Group .
Thanks in adavnce. |
|
| Back to top |
|
 |
| marko.pitkanen |
| Posted: Tue Jul 30, 2013 10:31 pm Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
Could you describe your problem with more detail? Now it seems to me too generic.
--
Marko |
|
| Back to top |
|
|
| atlas |
| Posted: Tue Jul 30, 2013 10:35 pm Post subject: |
|
|
Newbie
Joined: 03 Jul 2013
Posts: 6
|
| marko.pitkanen wrote: |
Hi,
Could you describe your problem with more detail? Now it seems to me too generic.
--
Marko |
Please find the error below.
( XXXXXX ) Broker ''ExeGrp'' (UUID "YYYY") was unable to retrieve an internal configuration response message for execution group ''ExeGrp' within the 360 second configuration timeout.
The execution group did not respond within the time period set by the broker's ConfigurationChangeTimeout parameter. A negative response is returned to the Configuration Manager for this execution group. The ConfigurationChangeTimeout parameter defines the maximum length of time in which an execution group can apply a deployed configuration change.
By default, the value of the ConfigurationChangeTimeout parameter is 300 seconds.
You can increase, and decrease, the timeout by using the mqsichangebroker command and changing the value of the ConfigurationChangeTimeout parameter. Changing this parameter does not resolve any underlying problem with the deployed message, but can 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 a problem with the execution group has been reported. Check that your system is not running short of resources; you might need to increase the WebSphere MQ log size, for example.
See the WebSphere Message Brokers online documentation section that describes the changing of timeouts that affect configuration tasks in the broker.
Reducing the complexity of the deployment by reducing the number of execution groups might also solve this problem.
Correct the problem and redeploy the broker's configuration by using the workbench, the mqsideploy command or Configuration Manager Proxy. If no other failure diagnostics are available, consider increasing the value of the ConfigurationChangeTimeout parameter in units of 300 until this message no longer occurs. Contact your IBM support center if you are unable to resolve the problem.
Could some help us.
Thank you. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Tue Jul 30, 2013 10:42 pm Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
What are versions your broker and toolkit?
How many artifacts are in and what is the size of the BAR -file you are trying to deploy?
Are deployment requests piling in the SYSTEM.BROKER... queues?
--
Marko |
|
| Back to top |
|
|
| atlas |
| Posted: Tue Jul 30, 2013 10:49 pm Post subject: |
|
|
Newbie
Joined: 03 Jul 2013
Posts: 6
|
| marko.pitkanen wrote: |
What are versions your broker and toolkit?
How many artifacts are in and what is the size of the BAR -file you are trying to deploy?
Are deployment requests piling in the SYSTEM.BROKER... queues?
--
Marko |
Hi Marko
The bar file size is 21 KB only which includes only message set.
In that execution group already 3 flows are running.
This happens in Acceptance Only where as in Production its working fine.
If any other info needed please lemme know.
Thanks in adavnce. |
|
| Back to top |
|
|
| atlas |
| Posted: Tue Jul 30, 2013 10:54 pm Post subject: |
|
|
Newbie
Joined: 03 Jul 2013
Posts: 6
|
| atlas wrote: |
| marko.pitkanen wrote: |
What are versions your broker and toolkit?
How many artifacts are in and what is the size of the BAR -file you are trying to deploy?
Are deployment requests piling in the SYSTEM.BROKER... queues?
--
Marko |
Hi Marko
The bar file size is 21 KB only which includes only message set.
In that execution group already 3 flows are running.
This happens in Acceptance Only where as in Production its working fine.
If any other info needed please lemme know.
Thanks in adavnce. |
Versions we are using are 6.1 for both Broker and Toolkit. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Jul 31, 2013 2:37 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| The error message you are receiving gives you some pointers and suggestions. Have you tried them ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 31, 2013 5:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| atlas wrote: |
| This happens in Acceptance Only where as in Production its working fine. |
Is this a new version of an existing flow(s)? If so, is the already deployed version hung up & unable to be replaced?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Wed Jul 31, 2013 10:14 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
If I would be in your shoes I would try following things: stop broker and configmgr and check SYSTEM.BROKER.* queues for hanging deployments. Start broker and configmgr and cancel deployments and remove artifacts that will be redeployed from EG and redeploy them. If this procedure doesn't work open PMR asap (because EOS for version 6.1 comes soon).
--
Marko |
|
| Back to top |
|
|
|
|
