Fixes are available
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21
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
Document Information
Modified date:
28 April 2022