The FCM buffer discarded message can be seen in db2diag.log on a
remote partition.
2013-08-05-01.09.07.477149+480 I16501733A701 LEVEL: Error
PID : 2294174 TID : 1543 PROC : db2sysc
10
INSTANCE: db2inst1 NODE : 010
EDUID : 1543 EDUNAME: db2fcmr 10
FUNCTION: DB2 UDB, fast comm manager,
sqkfFastCommManager::RouteInboundBuffer, probe:30
DATA #1 : <preformatted>
rc = 0x0; buffer addr: 7800000a3a39080
buffer info: channel ID=478015836, sender node=0, conduit ID=0,
sequenceNo=4294967295, sessionId=0, priority=0,
msgFlags=0x30009,
msgType=1
app_hdl=0-18506, app_stamp=594176, sourceNode=0, idtype=1,
idflags=0, bdsCounter=28, nestedCounter=0
(BDS) subtaskId=33, sendNode=0, intFlags=0x0, bdsFlags=0x2
(BQS) counter=33, node=0
DB2 has an internal unique counter called app_stamp based off
epoch time for each incarnation of an app-handle. But due to the
way DB2 calculates this unique number, it can wrap. Because the
unique identifier wraps, it caused a problem in the logic of
our code that ultimately lead to a buffer being discarded, and
an application being hung.
Note :
- On DB2 Version 9.7 or higher, EDUNAME is db2pdbc and the
FUNCTION is sqkfFastCommManager::DeliverBufferToTargetChannel,
probe:30
- This issue only applies to the DB2ﾩ partitioned database
environment.
- This issue also impacts pureScale instance. |
The FCM buffer discarded message can be seen in db2diag.log on a
remote partition.
2013-08-05-01.09.07.477149+480 I16501733A701 LEVEL: Error
PID : 2294174 TID : 1543 PROC : db2sysc
10
INSTANCE: db2inst1 NODE : 010
EDUID : 1543 EDUNAME: db2fcmr 10
FUNCTION: DB2 UDB, fast comm manager,
sqkfFastCommManager::RouteInboundBuffer, probe:30
DATA #1 : <preformatted>
rc = 0x0; buffer addr: 7800000a3a39080
buffer info: channel ID=478015836, sender node=0, conduit ID=0,
sequenceNo=4294967295, sessionId=0, priority=0,
msgFlags=0x30009,
msgType=1
app_hdl=0-18506, app_stamp=594176, sourceNode=0, idtype=1,
idflags=0, bdsCounter=28, nestedCounter=0
(BDS) subtaskId=33, sendNode=0, intFlags=0x0, bdsFlags=0x2
(BQS) counter=33, node=0
DB2 has an internal unique counter called app_stamp based off
epoch time for each incarnation of an app-handle. But due to the
way DB2 calculates this unique number, it can wrap. Because the
unique identifier wraps, it caused a problem in the logic of
our code that ultimately lead to a buffer being discarded, and
an application being hung.
Note :
- On DB2 Version 9.7 or higher, EDUNAME is db2pdbc and the
FUNCTION is sqkfFastCommManager::DeliverBufferToTargetChannel,
probe:30
- This issue only applies to the DB2© partitioned database
environment.
- This issue also impacts pureScale instance. |
