| Author |
Message
|
| rajasri |
 Posted: Sat Aug 02, 2008 1:52 am Post subject: execution group terminated |
 |
|
Centurion
Joined: 11 Jun 2006
Posts: 114
|
Hi All,
having a bad holiday toay. A execution group terminated abruptly i production and the error it shows is
Broker BRPX1004 (UUID 82ed952a-1801-0000-0080-e758728ca755) was unable to retrieve an internal configuration response message for execution group 'EG_POS_FIX' within the 360 second Configuration Timeout. : BRPX1004.agent: /build/S500_P/src/AdminAgent/ImbAdminAgent.cpp: 2400: ImbAdminAgent::receiveEGResponse: :
A problem was detected with WebSphere Business Integration while issuing MQOPEN for WebSphere Business Integration queue '47DF6AF22FCB243B', WebSphere Business Integration queue manager 'MQPX1004'. MQCC=2, MQRC=2085. : BRPX1004.agent: /build/S500_P/src/AdminAgent/ImbQueue.cpp: 207: ImbQueue::open: :
went through all sites and resources available to me. no help.
coul some one help please |
|
| Back to top |
|
 |
| rajasri |
| Posted: Sat Aug 02, 2008 2:26 am Post subject: reply |
|
|
Centurion
Joined: 11 Jun 2006
Posts: 114
|
Hi All,
we have bounced every thing and now i get a new message....
Aug 2 19:42:29 upeaib02 MQSIv500[1146976]: (BRPX1004)[1]BIP2066E: Broker BRPX1004 (UUID 82ed952a-1801-0000-0080-e758728ca755) was unable to retrieve an internal configuration response message for execution group 'EG_POS_FIX' within the 360 second Configuration Timeout. : BRPX1004.agent: /build/S500_P/src/AdminAgent/ImbAdminAgent.cpp: 2400: ImbAdminAgent::receiveEGResponse: :
I see that messages are piling up in SYSTEM.BROKER.EXECUTIONGROUP.QUEUE
an no messages in SYSTEM.BROKER.EXECUTIONREPLY.QUEUE.
So, I understand that the depoyment requests sent from configmgr to broker are fine, and requests from broker is sent to execution group, and broker is waiting for the reply from execution group and since it is not sending any replies, we are getting these errors. But the thing I dont understan is why is Execution group not replying...why is it not taking the messages put in the SYSTEM.BROKER.EXECUTIONGROUP.QUEUE......any help is appreciated...thanks in advance.. |
|
| Back to top |
|
|
| rajasri |
| Posted: Sat Aug 02, 2008 3:51 am Post subject: reply |
|
|
Centurion
Joined: 11 Jun 2006
Posts: 114
|
| increased the Confg Mgr heap size also.......no change.... |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Sat Aug 02, 2008 3:59 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi rajasri,
Did you monitor the momory usage of the execution group ? Is it increasing or looks fine ?
Were your flows already running in the execution group or this is the first time you deployed the flows ?
Can you tell what types of flows are running in the execution group...2085 means you have most probably specified an inexistant object name....waht queue is '47DF6AF22FCB243B' ?
Regards. |
|
| Back to top |
|
|
| rajasri |
| Posted: Sat Aug 02, 2008 4:06 am Post subject: Reply |
|
|
Centurion
Joined: 11 Jun 2006
Posts: 114
|
Hi Elvis,
Every thing is fine...this has been running in production for almost an year..an we have not change anything, if you see the error
A problem was detected with WebSphere Business Integration while issuing MQOPEN for WebSphere Business Integration queue '47DF6AF22FCB243B', WebSphere Business Integration queue manager 'MQPX1004'. MQCC=2, MQRC=2085. : BRPX1004.agent: /build/S500_P/src/AdminAgent/ImbQueue.cpp: 207: ImbQueue::open: :
it is trying to put the message into a queue which does not exist...and other thing is...when we restart the broker, the message flow takes the first message, and control goes to failure node and the error thrown is execution group may be down. and then the below message is put into syslog..
Aug 2 19:42:29 upeaib02 MQSIv500[1146976]: (BRPX1004)[1]BIP2066E: Broker BRPX1004 (UUID 82ed952a-1801-0000-0080-e758728ca755) was unable to retrieve an internal configuration response message for execution group 'EG_POS_FIX' within the 360 second Configuration Timeout. : BRPX1004.agent: /build/S500_P/src/AdminAgent/ImbAdminAgent.cpp: 2400: ImbAdminAgent::receiveEGResponse: :
every 6 min....so i dont think it is any problem with the message flow...some problem with the execution group itself.. |
|
| Back to top |
|
|
| elvis_gn |
| Posted: Sat Aug 02, 2008 7:38 am Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi rajasri,
If a message is being picked from the queue, then the execution group seems to be working, it's the flow which is looping somewhere as it's not able to put the message into the queue...just a routine guess...
Perhaps, you should purge or getInhibit all the input queues and remove all the flows in the execution group. Monitor the execution group while running the flows one by one.
And please explain how your error handling is working....are you putting messages to dynamic queues or something ?
Regards. |
|
| Back to top |
|
|
| nagarjun_vv |
| Posted: Mon Aug 04, 2008 2:36 am Post subject: hi |
|
|
Apprentice
Joined: 24 Jun 2008
Posts: 33
|
1.when first message is working and second message is not working most probably there is an infinite loop in the code.
2. How many instance you have given in the bar if it is more than one (say 5 then 5 message will enter the flow)
3. check the CPU utilization for that execution group.
I want to know whether any one deleted the EG or Broker and created a new EG or broker with same name (in this case also you may get this problem)
2085 error in which queue u r getting this one it is ur input queue or output queue .
check whether that queue is there or not.
Regards,
Nagarjun. |
|
| Back to top |
|
|
| rajasri |
| Posted: Mon Aug 04, 2008 9:01 pm Post subject: Reply |
|
|
Centurion
Joined: 11 Jun 2006
Posts: 114
|
Hi Nagarjun,
I never said that the first msg is working. If it is going in to a loop, it does not mean that it is working..right?.
Ok. The problem is solved. Our technical experts have come to the know the actual problem. We have Tivoli monitioring tool, which wants to get the status of the broker. this monitoring tool pretends it is the configMgr
and puts messages directly to the brokers SYSTEM.BROKER.ADMIN.QUEUE.
These messages ask our brokers for status of their execution groups
and message flows. These same type of status messages are used to
provide the information about the broker.
.
The broker sees these messages as internal operation messages, and
like other MQSeries messages, they have a ReplyToQ and ReplyToQMgr
in the MQMD. The broker administration agent uses these fields to
construct a response to the requestor. Therefore when the broker
issues a BIP2070E that reports it could not put an internal
configuration message, then it is attempting to put the Reply
message to the request that was put on its SYSTEM.BROKER.ADMIN.QUEUE.
.
If we cannot open this named queue, then it would suggest that the
requestor who put the message on this admininstration queue did
not specify the correct reply queue, or specified a dynamic queue
that was deleted before the broker could respond. In this case the
Tivoli monitoring product is either not specifying the correct ReplyTo
fields in its request message, or is not using a dynamic reply queue
fields in its request message, or is not using a dynamic reply queue
that gets deleted before the broker can respond.
.
This is not an MQSeries problem and is not a WMQI problem. The broker
cannot suppress these messages, because when it cannot respond to an
internal configuration request message, then it has to report it
because there could be a 'real' problem with internal communications
in the broker domain. This is the reason we were getting the error A problem was detected with WebSphere Business Integration while issuing MQOPEN for WebSphere Business Integration queue '47DF6AF22FCB243B', WebSphere Business Integration queue manager 'MQPX1004'. MQCC=2, MQRC=2085. : BRPX1004.agent: /build/S500_P/src/AdminAgent/ImbQueue.cpp: 207: ImbQueue::open: : .
SO we stopped the Tivoli tool, and these errors have stopped. We had to bounce off the box, and then every thing went fine. |
|
| Back to top |
|
|
|
|
