Re: "Phantom" Execution Groups - Websphere

This is a discussion on Re: "Phantom" Execution Groups - Websphere ; I don't know if you've already solved this problem or not, but I was previously told by support to set the ProcessState and DynamicState to 3 in the BROKERAAEG table, and this solution did originally work to kill the DataFlow ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: "Phantom" Execution Groups

  1. Re: "Phantom" Execution Groups

    I don't know if you've already solved this problem or not, but I was previously told by support to set the ProcessState and DynamicState to 3 in the BROKERAAEG table, and this solution did originally work to kill the DataFlow process and remove the EG entry from BROKERAAEG. However, now that I've created/deleted more EG's, I'm now at a point just like you where nothing works to make the DataFlow process go away or remove the entry from BROKERAAEG. In addition, when I execute "mqsilist -e ", I get a BIP29062E error saying the cfg msg sent contained an invalid XML tag. "mqsilist " does identify the deleted EG as still running. Perhaps the fact that I attempted to rename this EG before I deleted it threw everything out of sync.

    I haven't contacted support yet, but I'm wondering if deleting entries in BROKERAAEG and/or CEGCMSGFLOW would help. Let me know if you ever resolved this, and I'll try to post the response from support if I manage to solve it from my end. Thanks!

    Fulton

  2. Re: "Phantom" Execution Groups

    Thanks for the response.

    I actually did call support and resolved it in the manner you described - setting the ProcessState and DynamicState to 3. I actually stopped and restarted the Broker services (not just from the MQ Services console BUT also from the Windows Services tool). When I did that 1 of the 2 phantom "Test" eg's was actually removed (I don't know if its a timing / clean up issue while starting and it just didn't get to the other or what...). The one eg remained in the list BUT it is not actually running (process id is 0 and there is no associated dataflowengine process running).

    The following is the instructions provided by support:

    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 = ''
    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''
    AND ExecGroupUUID = x''

    b) Oracle Broker Database

    UPDATE BROKERAAEG
    SET ProcessState=3, DynamicState=3
    WHERE BrokerUUID= ''
    AND ExecGroupUUID = ''

    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 this helps,

    Jeff

+ Reply to Thread