IBM Support

PH52313: MEMORY LEAK IN JAXRS VECTOR

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

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