IBM Support



You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • After migrating a WebSphere MQ v7 classes for JMS application to
    the IBM MQ v8 classes for JMS, the application experiences
    decreased performance when connecting to pre-IBM MQ v8 queue
    managers using the CLIENT transport mode where the SHARECNV
    property on the server-connection channel in use has a value
    greater than 1.

Local fix

  • Set the channel property "SHARECNV" to have the value '1' for
    the channel which the application is using to communicate with
    the queue manager.

Problem summary

  • ****************************************************************
    Users of the IBM MQ classes for JMS v8.0 which are:
    (a) Communicating with a queue manager that predates version 8.0
    (b) Using a channel to establish a TCP/IP connection where the
    channel's SHARECNV property is set to a value greater than 1
    (c) Creating a total number of JMS Connections and JMS Sessions
    which exceeds the value of the SHARECNV property as defined on
    the channel.
    Platforms affected:
    MultiPlatform, AIX, HP-UX Itanium, IBM iSeries, Linux on Power,
    Linux on S390, Linux on x86, Linux on x86-64, Linux on zSeries,
    Solaris x86-64, Solaris SPARC, Windows, z/OS
    A performance optimisation in the IBM MQ v8.0 product is
    utilised by an IBM MQ v8.0 classes for JMS application such that
    with a specific configuration (primarily when a channel's
    SHARECNV value is set to the value '1'), a request for messages
    by the application are translated into a synchronous MQ-API call
    to the queue manager.
    When this is used, the queue manager channel instance process
    uses a dedicated thread to carry out the attempted retrieval of
    a message.
    For example, if a JMS application makes the method call:
    it is requesting to wait 30,000ms (or 30 seconds) for a message
    from a queue. When this v8.0 performance optimisation is in
    operation, the dedicated channel instance thread will receive
    the request from the application over TCP/IP, and make a
    synchronous MQGET call to the queue manager. While the thread
    does this, it cannot be used to service any other requests which
    are made over the channel instance. This synchronous method
    should only be used when SHARECNV=1, such that there will be no
    other requests over the channel instance from a client
    However, a program defect within the IBM MQ v8.0 classes for JMS
    meant that under a specific circumstance, this synchronous
    optimisation could be activated when communicating with a queue
    manager version earlier than v8.0 and where the SHARECNV value
    on the channel was greater than '1'.
    The consequence of this was that if multiple requests are being
    made over the same TCP/IP socket, the dedicated thread
    associated with the channel instance would service one after the
    other, meaning that the second and subsequent requests would be
    delayed until the previous was complete.
    For example, consider that two JMS Sessions are using the same
    TCP/IP socket to communicate with the queue manager. A
    MessageConsumer has been created from each Session, to consume
    messages from different queues on the queue manager.
    If the queue that "MessageConsumer_1" was consuming messages
    from contains no messages and requests a 30 second wait time on
    the receive call, "MessageConsumer_2" which makes a receive call
    to the different queue (which contains messages) must wait the
    30 seconds for the first operation to complete, eg:
    00:00:00 MessageConsumer_1.receive(30000)
    00:00:01 MessageConsumer_2.receive(30000)
    00:00:30 MessageConsumer_1 completes, returning no messages
    00:00:30 MessageConsumer_2 returns a message from the second
    To understand how JMS Sessions might share a TCP/IP connection
    and trigger this performance problem, we need to look at how
    MQ-JMS objects use 'hconns'.
    A 'hconn' is the object that is used by a thread to communicate
    with the queue manager. The number of 'hconns' which fit over a
    TCP/IP socket is that which is specified by the SHARECNV channel
    For example, for a default channel the SHARECNV value is 10.
    This means that 10 'hconns' can use the same TCP/IP socket. If
    an 11th 'hconn' is required, a new TCP/IP socket is created.
    For the MQ-JMS API, every JMS Session and JMS Connection use one
    'hconn'. The performance problem described by this APAR is only
    triggered when a JMS Session is created which triggers the
    generation of a new TCP/IP socket to a queue manager version
    which is less than v8.0.
    For example, consider the following application:
    (1) Application creates a JMS Connection (1 'hconn')
    (2) Application creates nine JMS Sessions from this Connection
    (9 'hconns').
    Now the TCP/IP socket is 'full'. The next JMS Connection or
    Session created will require a new TCP/IP socket.
    (3) Application creates a further 2 JMS Sessions from the above
    The first of these incorrectly negotiates with the queue manager
    to use this synchronous performance enhancement, and now all
    'hconns' created which use this TCP/IP socket will be affected
    by the single threading behaviour of the channel instance for
    the socket.

Problem conclusion

  • The IBM MQ classes for JMS have been updated to ensure that this
    new synchronous requesting performance feature is not enabled
    for a queue manager which is at a version less than v8.0.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    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


  • 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

  • R800 PSY


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

Document Information

Modified date:
25 August 2015