| Author |
Message
|
| venkat kurra |
 Posted: Tue May 03, 2005 1:21 pm Post subject: Two Execution groups with the same name??? |
 |
|
Master
Joined: 18 Oct 2001
Posts: 245
Location: Bloomington , IL
|
HI,
Any one seen two execution groups named exactly same and contents also same on a single Broker?
Few months back we deployed a Bar file to an Execution group called ExGrp1 on the broker. All of the sudden we see two execution groups with the same name and same contents(Flows & set). The mqsilist <broker> show both execution groups & process ids. Also you can see these two processes open the in put queue.
In genaral the toolkit won't allow to create an execution group which has already there.
We are at WBIMB 5.0,CSD4 on Windows 2000.
_________________
Thanks,
Venkat Kurra
IBM Certified Specialist-MQSeries
IBM Websphere MQSeries Administrator
IBM WebSphere Message Broker System Admin |
|
| Back to top |
|
 |
| JT |
| Posted: Tue May 03, 2005 2:15 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Venkat,
We've also encountered this scenario a couple of times (duplicate execution group and message flows/sets, multiple open handles on the input queue, etc..), exclusively in the 'development' environment (v5.04 on Unix). We allow the user community to create execution groups in that environment, and usually the problem has been attributed to an inexperienced developer. I'm a little fuzzy on the details, but I believe it's happened when a developer, with a message flow that contains a custom node, over-reacts when they were unable to deploy or stop the message flow, and then proceeds to remove the message flow from the execution group or they go as far as deleting the execution group from the broker (you can never get a straight answer after-the-fact).
The WBI administrator clears the unwanted occurrence by deleting a row from one of the broker tables. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 04, 2005 3:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This can happen when someone tries to use RAD to test a message flow and specifies an existing execution group name.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| venkat kurra |
| Posted: Wed May 04, 2005 7:31 am Post subject: |
|
|
Master
Joined: 18 Oct 2001
Posts: 245
Location: Bloomington , IL
|
Thanks JT.
Is this the right way to delete an execution group from the Broker Database?
Go to the DB2 Command line processor....
db2 => connect to <Broker database>
db2 => delete from BROKERAAEG where PROCESSID = <processid>
Bounce the broker service.
_________________
Thanks,
Venkat Kurra
IBM Certified Specialist-MQSeries
IBM Websphere MQSeries Administrator
IBM WebSphere Message Broker System Admin |
|
| Back to top |
|
|
| JT |
| Posted: Wed May 04, 2005 7:47 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
|
| Back to top |
|
|
| shra_k |
| Posted: Mon May 09, 2005 2:38 am Post subject: |
|
|
Apprentice
Joined: 30 Dec 2002
Posts: 37
|
Venkat (OSG),
Your problem could be related to the APAR IC42230 and an extract of the PRB 2414 is pasted here for you.
=============PRB 2414 (extract)=============
The procedure detailed below may be used to remove a rogue execution group from the broker. It should be noted that this should only be used in urgent situations where it is necessary to get the broker up and running again correctly.
First we need to establish the UUIDs of the execution groups that the Configuration Manager believes are deployed to the broker. Run the following SQL when connected to the Configuration Manager database to do this:
SELECT E.CBROKERCUUID, B.CNAME, E.CUUID, E.CNAME
FROM CBROKER AS B, CEG AS E
WHERE B.CNAME = '<brokername>'
AND B.CUUID = E.CBROKERCUUID
AND B.CSECTION = 'DEPLED'
AND E.CSECTION = 'DEPLED'
This will produce a list of the broker's UUID and name, along with the UUIDs and names of the execution groups that are deployed to the broker.
The next step is to determine the execution groups that are actually running on the broker by browsing the entries in the BROKERAAEG table in the broker database, as follows:
mqsibrowse -t BROKERAAEG > brokeraaeg.out
Now compare the entries in the brokeraaeg.out file against the output from the SELECT from the Configuration Manager table to determine the execution groups that are running in the broker that aren't reflected in the Configuration Manager database. These are the the candidates for deletion from the broker database.
Before proceeding to delete the execution groups from the broker database it is worth checking that there are no outstanding deploys from the Configuration Manager. To do this check the following:
1. There are no deploy messages on the SYSTEM.BROKER.ADMIN.QUEUE.
2. There are no deploy messages stuck on the transmission queue between the Configuration Manager's queue manager and the Broker's queue manager.
3. There are no outstanding deploys in the COUTSTANDING table in the Configuration Manager's database. Check this with the following SQL:
SELECT COUNT(*) FROM COUTSTANDING
If the count returned is greater than 0 then there are outstanding deploys which should be allowed to complete.
Once it has been verified that there are no outstanding deploys the 'rogue' execution groups can be removed from the broker database with the following SQL. Please note, it is strongly recommended that the broker is stopped and the broker database is backed up prior to manually updating database records.
1. Stop the broker if it is not already stopped.
2. Connect to the broker database as the broker service user ID.
3. Depending on the RDBMS that's used for the broker database, run the following SQL to remove each rogue execution group.
a) DB2 Broker Database
UPDATE BROKERAAEG
SET ProcessState=3, DynamicState=3
WHERE BrokerUUID= x'<UUID of Broker>'
AND ExecGroupUUID = x'<UUID of Execution Group>'
b) Oracle Broker Database
UPDATE BROKERAAEG
SET ProcessState=3, DynamicState=3
WHERE BrokerUUID= '<UUID of Broker in uppercase>'
AND ExecGroupUUID = '<UUID of Execution Group in uppercase>'
4. Restart the broker and ensure that the number of execution groups that are started reflects the number of execution groups that are displayed in the Tooling.
===========================================
Hope that helps, buddy (OSG).
Rgds,
Shra |
|
| Back to top |
|
|
| venkat kurra |
| Posted: Wed May 11, 2005 6:34 am Post subject: |
|
|
Master
Joined: 18 Oct 2001
Posts: 245
Location: Bloomington , IL
|
| Thanks Shra. This is a good one...I will try this. |
|
| Back to top |
|
|
| MQ_WBI_EXPERT |
| Posted: Thu May 12, 2005 5:58 am Post subject: |
|
|
Newbie
Joined: 12 May 2005
Posts: 1
|
We had the same problem when we did the HACMP failover testing in our AIX machine. We started seeing duplicate execution groups running under the same broker.
The only way to get rid off that problem is to stop the broker, it will stop some of the execution groups, then we have manually kill the process of other execution group issuing kill -9 process id . After doing this try to restart the broker and it should come up without any duplicate execution groups.
(I have raised a PMR with IBM a month ago, but still waiting for a solution.....)
Thanks
MQ_WBI_EXPERT. |
|
| Back to top |
|
|
|
|
