In certain circumstances DB2 applications may be delayed while
attempting to disconnect from a DB2 server running on the
Windows platform. This is most commonly encountered when "LOAD
from remote cursor" operations are occurring on other database
connections to the same server. Any application that was
connected prior to the start of the LOAD command that
subsequently tries to disconnect may appear to hang until the
LOAD completes. This issue affects only connections using the
TCP/IP protocol.
A stack trace on the application side will show the client
thread blocked in a TCP/IP receive call as part of disconnect
processing. For example, an application running on Linux may be
observed in a stack similar to the following for several minutes
or longer:
#0 0x00002aaaad5460e5 in recv () from /lib64/libc.so.6
#1 0x00002aaaab86d840 in tcprecv(SQLCC_COMHANDLE_T*, int,
char*, int, unsigned short, unsigned short,
SQLCC_TCPCONNHANDLE_T*, SQLCC_COND_T*, unsigned int, int*) ()
from /home/db2inst1/sqllib/lib/libdb2.so.1
#2 0x00002aaaab86d1cf in sqlcctcprecv(SQLCC_COMHANDLE_T*,
SQLCC_COND_T*) () from /home/db2inst1/sqllib/lib/libdb2.so.1
#3 0x00002aaaabc7d355 in sqlccrecv () from
/home/db2inst1/sqllib/lib/libdb2.so.1
#4 0x00002aaaabc8705b in sqljcReceive(sqljCmnMgr*) () from
/home/db2inst1/sqllib/lib/libdb2.so.1
#5 0x00002aaaab254ec8 in sqljrReceive(sqljrDrdaArCb*,
db2UCinterface*, bool) () from
/home/db2inst1/sqllib/lib/libdb2.so.1
#6 0x00002aaaaba3d3dd in sqljrDrdaArDisconnect(db2UCinterface*)
() from /home/db2inst1/sqllib/lib/libdb2.so.1
#7 0x00002aaaab1f5a88 in sqleUCdisconnect () from
/home/db2inst1/sqllib/lib/libdb2.so.1
#8 0x00002aaaab1f9bff in sqleUCappConnectReset () from
/home/db2inst1/sqllib/lib/libdb2.so.1
#9 0x00002aaaab3575ec in CLI_sqlDisconnect(CLI_CONNECTINFO*,
sqlca*, CLI_ERRORHEADERINFO*) () from
/home/db2inst1/sqllib/lib/libdb2.so.1
#10 0x00002aaaab33dcfb in SQLDisconnect2(CLI_CONNECTINFO*) ()
from /home/db2inst1/sqllib/lib/libdb2.so.1
#11 0x00002aaaab33d260 in SQLDisconnect () from
/home/db2inst1/sqllib/lib/libdb2.so.1
#12 0x0000000000403153 in CLIAppTerm ()
#13 0x000000000040262a in main ()
While the application is delayed a "db2 list applications" on
the server will not contain an entry for the application, but
"netstat" will still indicate the socket connection as
"ESTABLISHED".
The fix for this APAR is required only on the server side and
applies only to DB2 servers running on the Windows platform (32-
or 64-bit). |
