APAR status
Closed as program error.
Error description
JAXRS leak vector Three of the four application class loaders present in the dump with visible GC roots were referenced in the contextClassLoader field of ThreadPoolExecutor threads: Class Name | Shallow Heap | Retained Heap --------------------------------------------------------------- ------------------------------------------------------- com.ibm.ws.classloader.CompoundClassLoader @ 0x8153ddb0 app:demo-ear7 | 160 | 7,752 |- contextClassLoader java.lang.Thread @ 0x81540f08 pool-4-thread-1 JNI Global, Thread| 120 | 736 |- contextClassLoader java.lang.Thread @ 0x81540f80 pool-4-thread-2 JNI Global, Thread| 120 | 736 |- contextClassLoader java.lang.Thread @ 0x81540ff8 pool-4-thread-3 JNI Global, Thread| 120 | 736 '- contextClassLoader java.lang.Thread @ 0x81541070 pool-4-thread-4 JNI Global, Thread| 120 | 736 --------------------------------------------------------------- ------------------------------------------------------- References from running threads prevent GC, so any thread created in an application context must be stopped when the application is stopped (or have its context class loader set to a non-application class loader) in order to avoid leaking the class loader. Most of these thread pools appear to be abandoned, but I was able to trace one back, through what I believe is the instance of the application that was still running. That pool appears to have been created not by the application, but by the WAS CDI component: Class Name | Shallow Heap | Retained Heap --------------------------------------------------------------- ------------------------------------------------- workers java.util.concurrent.ThreadPoolExecutor @ 0x8155b180 | 80 | 488 '- executorService com.ibm.ws.cdi.impl.weld.ExecutorServicesImpl @ 0x84118358 | 16 | 16 --------------------------------------------------------------- -------------------------------------------------
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server * * with applications that include an EJB jar * * file. * **************************************************************** * PROBLEM DESCRIPTION: JAXRS is not always cleaning * * the routerEJBMetaDataCache when * * applications are stopped, causing a * * slow * * memory leak. * **************************************************************** * RECOMMENDATION: * **************************************************************** When an application containing an EJB jar file is started, JAXRS processing will add entries to the routerEJBMetaDataCache. These entries are not always cleaned up and therefore when applications are started and stopped repeatedly, without a restart of the server, a memory leak can occur over time.
Problem conclusion
This problem is now resolved by cleaning the routerEJBMetaDataCache when applications are stopped. The fix for this APAR is targeted for inclusion in fix pack 9.0.5.16 and 8.5.5.24. For more information, see 'Recommended Updates for WebSphere Application Server': https://www.ibm.com/support/pages/node/715553
Temporary fix
Comments
APAR Information
APAR number
PH52313
Reported component name
WEBS APP SERV N
Reported component ID
5724H8800
Reported release
900
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2023-02-01
Closed date
2023-05-02
Last modified date
2023-05-02
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WEBS APP SERV N
Fixed component ID
5724H8800
Applicable component levels
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
03 May 2023