IT33500: MQ-JMS Connection's ExceptionListener is not called when a JMS Session's TCP/IP socket is disconnected

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 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