APAR status
Closed as program error.
Error description
A JMS application is using a single JMS Connection with 15 JMS Sessions created from it, and connecting to a queue manager over a CHANNEL with the attribute: SHARECNV(10) A JMS ExceptionListener is registered against the JMS Connection, to be called in the event of a connection problem. When the TCP/IP socket is disconnected that the JMS Session is communicating to the queue manager over, and not the one used by the JMS Connection, the JMS ExceptionListener is not immediately called. Instead it is called when the application next attempts to use the disconnected JMS Session.
Local fix
Problem summary
**************************************************************** USERS AFFECTED: Users of the MQ classes for JMS API who are making use of JMS ExceptionListeners. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: The MQ classes for JMS make use of a logical unit called an 'hconn' for communication with the queue manager. If the connection to the queue manager is over TCP/IP, then the 'hconns' are shared over a TCP/IP socket in accordance with the CHANNEL attribute: SHARECNV which defaults to the value '10' - meaning that in the default configuration, up to 10 'hconns' can share a single TCP/IP socket. This could comprise the 'hconns' associated with JMS Connections and Sessions - for example 1 JMS Connection and 9 JMS Sessions could share the same TCP/IP socket in the default CHANNEL configuration. Every MQ-JMS Connection and MQ-JMS Session has a single 'hconn' associated with it. There is no requirement that the 'hconns' associated with a JMS Session must use the same TCP/IP socket as the JMS Connection. For example, consider the following configuration: CHANNEL SHARECNV(2) 1 x JMS Connection ('hconn_1') 2 x JMS Sessions ('hconn_2' and 'hconn_3') If no other MQ classes for JMS activity is present in the system and each JMS artifact was created sequentially, we would expect this to communicate with the queue manager over TCP/IP using two TCP/IP connections: TCP/IP socket 1: 'hconn_1' and 'hconn_2' TCP/IP socket 2: 'hconn_3' If the application had registered an ExceptionListener against the JMS Connection, eg by making the method call: javax.jms.Connection.setExceptionListener(javax.jms.ExceptionLis tener) then it was expected that if TCP/IP socket 2 was disconnected from the queue manager, the JMS ExceptionListener would be immediately driven by the MQ classes for JMS, in order to notify the application that a problem with the connection to the queue manager has occurred. However this was not the case. If the socket containing the 'hconn' associated with the JMS Connection was disconnected, the ExceptionListener would be immediately driven. However if the TCP/IP socket only contained JMS Session 'hconns', the ExceptionListener would not be driven until the application attempted to use the JMS Session. As a net result, the application would not be notified of the disconnected TCP/IP socket when it was first detected.
Problem conclusion
The MQ classes for JMS have been updated to ensure that when a problem with the TCP/IP socket to the queue manager is detected, the ExceptionListener is immediately driven, even when the JMS Connection's 'hconn' is still connected to the queue manager over a different TCP/IP socket. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.16 v9.0 LTS 9.0.0.12 v9.1 LTS 9.1.0.8 v9.2 LTS 9.2.0.5 v9.x CD 9.2.5 The latest available maintenance can be obtained from 'WebSphere MQ Recommended Fixes' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037 If the maintenance level is not yet available information on its planned availability can be found in 'WebSphere MQ Planned Maintenance Release Dates' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309 ---------------------------------------------------------------
Temporary fix
Comments
APAR Information
APAR number
IT33500
Reported component name
IBM MQ BASE MP
Reported component ID
5724H7251
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-07-10
Closed date
2021-02-24
Last modified date
2022-01-21
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
IBM MQ BASE MP
Fixed component ID
5724H7251
Applicable component levels
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.0.0","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
21 July 2022