I have been facing an issue with my Execution Groups in my Testing Environment. The EG names were changed to ‘DiscoveredEG_<UUID of the EG> and then finally the message flows deployed in different EGs of that particular broker was not responding to the input messages. We have finally resolved the issue. So I just thought of sharing it so that it may help dome one in future.
Basically the ‘DiscoveredEG’ issue happens when the periodic synchronization between broker and configuration manager fails. This is a synchronous call and if the response from Broker fails to commit the message to SYSTEM.ADMIN.BROKER.QUEUE, the message will be backed out and hence configuration manager will receive an empty message as response from the broker. It can be because of various reasons like MQ Logs became full and the message will be backed out. As a result configuration manager will update its repository with empty names there by removing the EG names from its repository. When the next successful synchronization happens, EG names in configuration manager repository will be updated, but with ‘DiscoveredEG_<UUID of the EG>’.
In my case the root cause of the issue was MQ logs. As we had high volume of messages coming in and we didn’t set our MQ logs properly, the COMMIT operation was failing and we were getting error messages in /var/adm/messages. The error message was as given below
“WebSphere Broker v6102[6512]: [ID 702911 user.error] (<Broker Name>)[1]BIP2074E: A problem was detected with WebSphere MQ while issuing MQCMIT for WebSphere MQ Queue Manager '<Queue Manager Name>'. MQCC=1, MQRC=2003”. We started our analysis with the MQRC code 2003 which helped us to understand that the MQ logs are full. I followed the below steps
1. I increased the number of both primary and secondary MQ Logs. This can achieved by editing the qm.ini file and restarting the queue manager.
2. The EG names will be still showing as ‘DiscoveredEG_<UUID of the EG>’ in Toolkit. In order to bring it back to the old names, rename the EGs based on the UUIDs using Toolkit. Take extreme care while doing it because by mistake if you rename with a different name, it will result in the UUID mismatch and more complexities.
3. After renaming, restart the message flows in the renamed EGs through Toolkit in order to reflect the changed EG names in Broker Database. Once this is completed successfully, ‘DiscoveredEG’ issue is resolved and you will have your EG names back in place.
Basically the ‘DiscoveredEG’ issue happens when the periodic synchronization between broker and configuration manager fails. This is a synchronous call and if the response from Broker fails to commit the message to SYSTEM.ADMIN.BROKER.QUEUE, the message will be backed out and hence configuration manager will receive an empty message as response from the broker. It can be because of various reasons like MQ Logs became full and the message will be backed out. As a result configuration manager will update its repository with empty names there by removing the EG names from its repository. When the next successful synchronization happens, EG names in configuration manager repository will be updated, but with ‘DiscoveredEG_<UUID of the EG>’.
In my case the root cause of the issue was MQ logs. As we had high volume of messages coming in and we didn’t set our MQ logs properly, the COMMIT operation was failing and we were getting error messages in /var/adm/messages. The error message was as given below
“WebSphere Broker v6102[6512]: [ID 702911 user.error] (<Broker Name>)[1]BIP2074E: A problem was detected with WebSphere MQ while issuing MQCMIT for WebSphere MQ Queue Manager '<Queue Manager Name>'. MQCC=1, MQRC=2003”. We started our analysis with the MQRC code 2003 which helped us to understand that the MQ logs are full. I followed the below steps
1. I increased the number of both primary and secondary MQ Logs. This can achieved by editing the qm.ini file and restarting the queue manager.
2. The EG names will be still showing as ‘DiscoveredEG_<UUID of the EG>’ in Toolkit. In order to bring it back to the old names, rename the EGs based on the UUIDs using Toolkit. Take extreme care while doing it because by mistake if you rename with a different name, it will result in the UUID mismatch and more complexities.
3. After renaming, restart the message flows in the renamed EGs through Toolkit in order to reflect the changed EG names in Broker Database. Once this is completed successfully, ‘DiscoveredEG’ issue is resolved and you will have your EG names back in place.
No comments:
Post a Comment