IBM Support

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

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.


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:
    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 of the MQ classes for JMS API who are making use of JMS
    Platforms affected:
    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:
    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:
    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:
    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
    v9.0 LTS
    v9.1 LTS
    v9.2 LTS
    v9.x CD    9.2.3
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • 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


  • Fixed component ID


Applicable component levels

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":""}]

Document Information

Modified date:
26 February 2021