|
Problem IC75993
|
Status: Closed |
Hung in AppStopUsing -> ForwardStopRequest due to other coord-ag entnot cleaning up its associated application value |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| 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. |
| 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 *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.7 Fix Pack 5 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
This defect will be fixed in v97 FP5 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 25.04.2011
25.06.2011
25.06.2011 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP5
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.5
|
 |
