IBM Support

PH09750: HANGING THREADS IN COM.IBM.EJS.JMS.JMSQUEUECONNECTIONHANDLE.CREATEQUEUESESSION

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Hanging threads may occur in WebSphere Application Server
    when attempting to create a JMS Session from a JMS
    Connection if the Connection is being shared across multiple
    threads.
    
    This typically results in a WSVR0605W message in the logs of
    the form:
    
    ThreadMonitor W WSVR0605W: Thread "WebContainer : 44"
    (00000173) has been active for 607775 milliseconds and may be
    hung. There is/are 2 thread(s) in total in the server that may
    be hung.
    at
    com.ibm.ejs.jms.JMSQueueConnectionHandle.createQueueSession(JMSQ
    ueueConn
    ectionHandle.java:204)
    at
    ...
    
    Javacores will show multiple threads waiting for the same
    intrinsic lock with the lock holder waiting in the J2C pool
    for a session to become free.
    
    The issue could occur in all variants of the methods to create
    JMS Sessions from all variants of JMS Connections.  eg
    com.ibm.ejs.jms.JMSTopicConnectionHandle.createTopicSession etc
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  WebSphere Application Server users of JMS   *
    *                  that share a JMS Connection across          *
    *                  multiple threads concurrently.              *
    ****************************************************************
    * PROBLEM DESCRIPTION: Threads may hang when creating JMS      *
    *                      Sessions when using JMS Connections     *
    *                      that are used concurrently on multiple  *
    *                      threads.                                *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    JMS Connections act as factories for JMS Sessions.  The
    various methods that are used for creating Sessions contained
    sycnhronization that spanned the request to retrieve a
    Session from the J2C pool.
    This causes inefficiencies in general but can also cause
    deadlocks for applications that create and close shared
    Sessions multiple times while performing a unit of work (the
    standard get-use-close model).
    In this scenario the closed shared Session is returned to the
    pool in a state whereby it is still associated with the unit of
    work and further createSession requests will allow the Session
    to be reused by the same unit of work, the Session only
    becoming free once the unit of work completes. However in such
    a scenario when the Session pool is full a thread requesting a
    Session for the first time will block waiting for a Session to
    become free, but the units of work with which the Sessions are
    associated may not be able to progress because they are waiting
    to retrieve the Session from the pool that is already
    associated with their unit of work.  This causes a deadlock
    situation which will only be resolved when the timeout value
    for creating connections from the J2C pool is reached.
    

Problem conclusion

  • The synchronization used in the various JMS Connection
    wrappers was modified so that it no longer spans the request
    to obtain the connection from the J2C pool.
    
    The fix for this APAR is currently targeted for inclusion in
    fix packs 8.5.5.16 and 9.0.5.0.  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

    PH09750

  • Reported component name

    WEBS APP SERV N

  • Reported component ID

    5724H8800

  • Reported release

    850

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2019-03-15

  • Closed date

    2019-06-24

  • Last modified date

    2019-06-24

  • 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

  • R800 PSY

       UP

  • R850 PSY

       UP

  • R900 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.5","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
28 April 2022