MQSeries.net :: View topic

coolsri · Posted: Thu Aug 21, 2008 11:21 pm Post subject:

Hi All,

We are having a strange situation. In one of our message flow, after getting an ODBC exception from Oracle database, it failed to detach the thread from JVM and the entire execution group is not responding. We have to restart the broker to work..

After ODBC exception, which we are handling using try catch, we getting the following message.

( ExeGrp) Failed to detach thread from the JVM.

The broker creates a Java Virtual Machine to support internal operations. This error indicates that there has been an internal problem using the JVM.

This is an internal error and you should contact your IBM support center.

After that we are constantly getting the following exception.

( 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.