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

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:
  
  
  com.ibm.mq.jmqi.remote.impl.RemoteConnectionPool:allConnectionSp
  ecs
  

Local fix

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

Problem summary

• ****************************************************************
  USERS AFFECTED:
  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:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  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
  thrown.
  

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

  5724H7271

Applicable component levels