PK01638: REPAIR MEMORY LEAK FOR SPAWNED USER THREADS. | |||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description Customer ran their code for a 70 hour test and could see memory being filled up as it went along. After 70 hours, memory full. Application Server had to be rebooted to continue. Found memory leak. Determined memory leak is from spawned user threads . In another scenario a customer had notice from the java garbage collection trace that the amount of heap being freed had been gradually decreasing over a week. . Collecting a console dump, and running the findroots tool with PrintDomTree to print the root that references the largest amount of space showed . com/ibm/ejs/j2c/HandleList . contained numerous objects of the same type. In this case: . com/ibm/ejs/jms/JMSQueueConnectionHandle . Note: This problem does not occur on Websphere V5.1 for z/os.Local fix Problem summary **************************************************************** * USERS AFFECTED: All users of WebSphere Application Server * * V5.0 for z/OS * **************************************************************** * PROBLEM DESCRIPTION: A memory leak can occur, (potentially * * resulting in the throwing of a * * java.lang.OutOfMemoryError), in * * connection management code. This * * problem can occur from an application * * accessing JDBC, JCA, or JMS resources * * from an application-spawned thread or * * from an application component using * * the direct lookup style of resource * * lookup (rather than the resource * * reference style). * **************************************************************** * RECOMMENDATION: * **************************************************************** This memory leak can occur when accessing JDBC, JCA, or JMS resources managed by WebSphere Application Server for z/OS from an application-spawned thread or from an application component which uses direct JNDI lookup rather than resource reference JNDI lookup (i.e. JNDI lookup in the component's java:comp/env namespace) to obtain its ConnectionFactory or DataSource resources. Connection handles opened from either type of component may end up being incorrectly tracked as orphaned handles, without these handles ever being released from memory, even when the application component closes the handles. The problem can cause an excessive amount of JVM heap memory to be consumed by a WebSphere Application Server for z/OS address space and possibly a OutOfMemoryError appearing in the servant. This problem could be identified from a JVM heap dump by noticing the following chain of object references: "class com/ibm/ejs/j2c/HandleList" has a reference to an object of type "java/util/ArrayList" which would have references to many connection handles, e.g. many refs to objects of type "com/ibm/ejs/jms/QueueConnectionHandle", which are the leaked objects. As a reminder, please note that neither of these two application programming models, (accessing JDBC/JCA/JMS via application-spawned threads nor direct lookup of JDBC/JCA/JMS resources), is recommended by IBM.Problem conclusion Code was modified to add nullContextHandles, a list of handles that were opened or closed when no HandleList was present on the thread, in order to track handles created by application components using these programming models. When the application closes its handles they are released from this new list allowing for garbage collection. APAR PK01638 is associated with SERVICE LEVEL W502025 of WebSphere Application Server V5.0 for z/OS.Temporary fix Comments
APAR is sysrouted FROM one or more of the following: PQ77890 APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Document Information |
Current web document: swg1PK01638.html
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server for z/OS
Operating system(s):
Software version: 500
Software edition:
Reference #: PK01638
IBM Group: Software Group
Modified date: Apr 1, 2005
(C) Copyright IBM Corporation 2000, 2009. All Rights Reserved.