IBM Support

IT29114: Memory leak in the MQ Java client after a failed connection attempt using a custom SSLSocketFactory

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

  • An IBM MQ classes for JMS or MQ classes for Java application
    attempts to create a TLS connection to a queue manager using a
    custom SSLSocketFactory object.  The connection request fails.
     This might be because the queue manager or listener is not
    running, for example.  The application then enters a retry loop,
    periodically attempting to create new connection.  For each
    connection attempt, the application recreates the required
    SSLSocketFactory object.
    After a large number of failed connections, the Java virtual
    machine throws a java.lang.OutOfMemoryError.  The heap dump
    produced by the JVM shows large amount of memory allocated to
    the following HashMap:

Local fix

  • Reuse the same SSLSocketFactory object for each new connection
    attempt.  Do not recreate it for each new connection request.

Problem summary

  • ****************************************************************
    This issue affects IBM MQ classes for JMS and classes for Java
    applications that attempt to create TLS connections using a
    custom SSLSocketFactory.
    Platforms affected:
    The Java MQI (JMQI) which underpins the IBM MQ classes for JMS
    and MQ classes for Java maintains a collection of objects that
    describe how to connect to a particular remote queue manager.
    These objects are called RemoteConnectionSpecification objects
    and are created when a new connection is requested by an
    application.  Channel instances are associated with a single
    RemoteConnectionSpecification and made available for
    multiplexing further connection requests when permitted.
    A hash value created from a RemoteConnectionSpecification object
    is used to determine whether it exists in a collection of all
    active RemoteConnectionSpecification objects ( i.e. those with
    running and non-full channel instances).  If a matching
    RemoteConnectionSpecification object exists, it is returned from
    the collection and used to either multiplex a new connection
    (also known as a conversation) over one of its existing channel
    instances or to create new one.  If no matching
    RemoteConnectionSpecification object is found, it is added to
    the collection.  RemoteConnectionSpecification objects are
    removed from the collection when all existing channel instances
    cannot multiplex any further conversations or an connection
    error on an existing channel instance is detected.
    If a RemoteConnectionSpecification object was added to the
    collection but a new channel instance could not be created, an
    exception would be returned to the application.  However the
    RemoteConnectionSpecification object would not be removed from
    the collection.  If the application configured a custom
    SSLSocketFactory (for example on a JMS Connection Factory) and
    it recreated the SSLSocketFactory object every time it attempted
    to create a connection, the hash value of the
    RemoteConnectionSpecification object for that connection attempt
    would differ from any previous RemoteConnectionSpecification
    objects.  This was because the hash value of the
    SSLSocketFactory would also have changed and this was used in
    the creation of the hash value of the
    RemoteConnectionSpecification object.
    The result was that no matching RemoteConnectionSpecification
    objects were returned from the collection and the newly created
    one added.  As more connection attempts failed, the collection
    increased in size as more RemoteConnectionSpecification objects
    were added and never removed.  This lead to the
    java.lang.OutOfMemoryError for heap space exhaustion being

Problem conclusion

  • The Java MQI (JMQI) logic for maintaining the collection of
    RemoteConnectionSpecification objects has been updated such that
    if a new channel instance cannot be allocated on a particular
    RemoteConnectionSpecification object, the
    RemoteConnectionSpecification is removed from the collection.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.1 LTS
    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

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
29 May 2019