IBM Support

PI61468: Application classloaders are leaked by transaction monitoring th reads.

Fixes are available

16.0.0.2: WebSphere Application Server Liberty 16.0.0.2
16.0.0.3: WebSphere Application Server Liberty 16.0.0.3
16.0.0.4: WebSphere Application Server Liberty 16.0.0.4
17.0.0.1: WebSphere Application Server Liberty 17.0.0.1
17.0.0.2: WebSphere Application Server Liberty 17.0.0.2
17.0.0.3: WebSphere Application Server Liberty 17.0.0.3
17.0.0.4: WebSphere Application Server Liberty 17.0.0.4
18.0.0.1: WebSphere Application Server Liberty 18.0.0.1
18.0.0.2: WebSphere Application Server Liberty 18.0.0.2
18.0.0.3: WebSphere Application Server Liberty 18.0.0.3
18.0.0.4: WebSphere Application Server Liberty 18.0.0.4
19.0.0.1: WebSphere Application Server Liberty 19.0.0.1
19.0.0.2: WebSphere Application Server Liberty 19.0.0.2
19.0.0.3: WebSphere Application Server Liberty 19.0.0.3
19.0.0.4: WebSphere Application Server Liberty 19.0.0.4
19.0.0.5: WebSphere Application Server Liberty 19.0.0.5
19.0.0.6: WebSphere Application Server Liberty 19.0.0.6
19.0.0.7: WebSphere Application Server Liberty 19.0.0.7
19.0.0.8: WebSphere Application Server Liberty 19.0.0.8
19.0.0.9: WebSphere Application Server Liberty 19.0.0.9
19.0.0.10: WebSphere Application Server Liberty 19.0.0.10
19.0.0.11: WebSphere Application Server Liberty 19.0.0.11
19.0.0.12: WebSphere Application Server Liberty 19.0.0.12
20.0.0.1: WebSphere Application Server Liberty 20.0.0.1
20.0.0.2: WebSphere Application Server Liberty 20.0.0.2
20.0.0.3: WebSphere Application Server Liberty 20.0.0.3
20.0.0.4: WebSphere Application Server Liberty 20.0.0.4
20.0.0.5: WebSphere Application Server Liberty 20.0.0.5
20.0.0.6: WebSphere Application Server Liberty 20.0.0.6
20.0.0.7: WebSphere Application Server Liberty 20.0.0.7
20.0.0.8: WebSphere Application Server Liberty 20.0.0.8
20.0.0.9: WebSphere Application Server Liberty 20.0.0.9
20.0.0.10: WebSphere Application Server Liberty 20.0.0.10
20.0.0.11: WebSphere Application Server Liberty 20.0.0.11
20.0.0.12: WebSphere Application Server Liberty 20.0.0.12

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The WebSphere Liberty transaction manager creates its own
    Executor thread pool during application startup.  These
    threads are used for tasks like timing out hung
    transactions, etc.  Since these threads are created lazily
    (that is, not until an application actually needs to use
    transactions), the thread that creates these threads will
    have an application's classloader set as its context
    classloader.  That classloader will then be set as the
    context classloader for the newly created transaction
    threads. When that application is stopped, the application's
    classloader should be able to be garbage collected, but the
    garbage collector is prevented from collecting this
    classloader because the transaction threads still have a
    strong reference to it.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server Liberty                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: Application classloaders are leaked by  *
    *                      transaction monitoring threads.         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The WebSphere Liberty transaction manager creates its own
    Executor thread pool during application startup.  These threads
    are used for tasks like timing out hung transactions, etc.
    Since these threads are created lazily (i.e. not until an
    application actually needs to use transactions), the thread that
    creates these threads will have an application's classloader set
    as its context classloader.  That classloader will then be set
    as the context classloader for the newly created transaction
    threads. When that application is stopped, the application's
    classloader should be able to be garbage collected, but the
    garbage collector is prevented from collecting this classloader
    because the transaction threads still have a strong reference to
    it.
    

Problem conclusion

  • The fix for this APAR is to ensure that newly created
    transaction threads do not reference the application's
    classloader, thus preventing the leak.
    
    The fix for this APAR is currently targeted for inclusion in fix
    pack 16.0.0.2.  Please refer to the Recommended Updates page for
    delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI61468

  • Reported component name

    WAS LIBERTY COR

  • Reported component ID

    5725L2900

  • Reported release

    855

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-04-26

  • Closed date

    2016-05-04

  • Last modified date

    2016-06-22

  • 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

    WAS LIBERTY COR

  • Fixed component ID

    5725L2900

Applicable component levels

  • R855 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SSD28V","label":"WebSphere Application Server Liberty Core"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"855","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
15 October 2021