IBM Support

IC75993: Hung in AppStopUsing -> ForwardStopRequest due to other coord-ag entnot cleaning up its associated application value

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • If an application pooled sub-agent was chosen as coord-agent and
    failed prior connecting to db (e.g. can not find the database
    name/alias, or we found a more suitable agent to handle this
    request), it might not disassociate the application completely.
    
    And this could cause the later code path in
    AppStopUsing->ForwardStopRequest to hung, since coord-agent that
    goes back to pool should not have associated application value
    set
    
    The following is the scenario:
    
    1.) if agent-X was started as sub-agent
    2.) did his work as sub-agent and finish
    3.) went back to its associated application sub-agent pool
    4.) moments later agent-X was chosen to serve a new connection
    5.) became a coord-agent
    6.) and failed prior connecting to db
         e.g. can not find the database name/alias,
                or we found a more suitable agent to handle
                this request)
    
    7.) and then coord-agent X went back to a pool with its
    associated application value set.
    
    
    Note that: coordinator agents do NOT maintain an application
    association when in the pool. Hence the defect on the scenario
    above.
    
    This could cause database related operation
    (backup/quiesce/activate/deactivate/etc) would not return and
    wait forever until agent-X terminate,
    so that would be a potential risk of this problem.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * ALL                                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    * If an application pooled sub-agent was chosen as coord-agent *
    * and failed prior connecting to db (e.g. can not find the     *
    * database name/alias, or we found a more suitable agent to    *
    * handle this request), it might not disassociate the          *
    * application completely.                                      *
    *                                                              *
    * And this could cause the later code path in                  *
    * AppStopUsing->ForwardStopRequest to hung, since coord-agent  *
    * that goes back to pool should not have associated            *
    * application value set.                                       *
    *                                                              *
    * The following is the scenario:                               *
    *                                                              *
    * 1.) if agent-X was started as sub-agent                      *
    * 2.) did his work as sub-agent and finish                     *
    * 3.) went back to its associated application sub-agent pool   *
    * 4.) moments later agent-X was chosen to serve a new          *
    * connection                                                   *
    * 5.) became a coord-agent                                     *
    * 6.) and failed prior connecting to db                        *
    * e.g. can not find the database name/alias,                   *
    * or we found a more suitable agent to handle                  *
    * this request)                                                *
    *                                                              *
    * 7.) and then coord-agent X went back to a pool with its      *
    * associated application value set.                            *
    *                                                              *
    * Note that: coordinator agents do NOT maintain an application *
    * association when in the pool. Hence the defect on the        *
    * scenario above.                                              *
    *                                                              *
    * This could cause database related operation                  *
    *                                                              *
    * (backup/quiesce/activate/deactivate/etc) would not return    *
    * and wait forever until agent-X terminate, so that would be a *
    * potential risk of this problem.                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    * Upgrade to DB2 v9.7 FP5                                      *
    ****************************************************************
    

Problem conclusion

  • This defect will be fixed in v97 FP5
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC75993

  • Reported component name

    DB2 FOR LUW

  • Reported component ID

    DB2FORLUW

  • Reported release

    970

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-04-25

  • Closed date

    2011-06-25

  • Last modified date

    2011-06-25

  • APAR is sysrouted FROM one or more of the following:

    IC75552

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    DB2 FOR LUW

  • Fixed component ID

    DB2FORLUW

Applicable component levels

  • R950 PSN

       UP

  • R970 PSN

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSEPGG","label":"DB2 for Linux, UNIX and Windows"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.7","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
25 June 2011