IT20943: A MQ JMS MessageConsumer.receive(long) call may not immediately return when closing the consumer

APAR status

• Closed as program error.

Error description

• An application is using the IBM MQ classes for JMS, and issues
  the method call:
  
    javax.jms.MessageConsumer.receive(3600000);
  
  which instructs the MQ classes for JMS to wait a maximum of 1
  hour for a message to become available on the destination if one
  is not present immediately.
  
  After 10 minutes, the application elects to close the
  MessageConsumer in order to shut the application down, which is
  expected to interrupt and abort the receiving thread's receive
  call.
  However this does not happen - the receiving thread is not
  interrupted, and remains in the receive call for the remainder
  of the wait interval.
  
  The net result is that the application takes far longer to shut
  down than was desired.
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects IBM MQ classes for JMS applications that are
  making use of the message receive method calls:
  
    javax.jms.MessageConsumer.receive(long interval)
    javax.jms.MessageConsumer.receive()
  
  where the JMS Connection which was used to create the associated
  JMS Session is connecting to the queue manager using the CLIENT
  transport type, over a CHANNEL with the configuration:
  
    SHARECNV(1)
  
  and the TCP/IP connection associated with the JMS Connection has
  been disconnected from the queue manager, but work under the
  associated JMS Session is continuing to be undertaken.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When connecting to the queue manager using the CLIENT transport
  type (that is to say, using TCP/IP to communicate with the queue
  manager), a 'hconn' is associated with both the JMS Connection
  and Session(s).
  
  These 'hconns' share a physical TCP/IP socket in accordance with
  the queue manager's CHANNEL property 'SHARECNV', which defaults
  to the value 10.  This means that in the default configuration,
  there can be up to 10 'hconns' sharing same physical TCP/IP
  socket for communication with the queue manager.
  
  The 'hconns' are assigned to the TCP/IP socket on a first come,
  first serve basis.  There is no correlation with the
  distribution of 'hconns' over the available TCP/IP sockets, and
  the relationship of the JMS Connections and Sessions.
  
  As a consequence, it is possible that a 'hconn' for a JMS
  Connection, and the associated JMS Session's 'hconn' are
  communicating with the queue manager over separate TCP/IP
  sockets.
  
  
  Once created, the communication over the JMS Connection's
  'hconn' is limited to a small number of uses.  One such use is
  when connected over a channel with the configuration
  'SHARECNV(1)', is to interrupt another thread which is being
  used to consume a message, using a MessageConsumer created from
  a JMS Session which in turn was created from the JMS Connection.
  
  
  The problem being addressed by this APAR is that if an
  application was operating over an unreliable network, it was
  possible that the JMS Connection's associated TCP/IP socket (and
  hence, its 'hconn'), becomes disconnected from the queue
  manager.  In this scenario, a MessageConsumer associated with
  the now-disconnected JMS Connection would continue to function,
  however there was no mechanism to interrupt a waiting
  MessageConsumer if the application attempted to end the receive
  call prematurely.
  
  
  To explain this in more detail with an example, consider the
  following code snippets and times when events might occur:
  
  00:00 Create a Connection, connecting over a SHARECNV(1) channel
      ConnectionFactory.createConnection()
  
  00:01 Create a JMS Session
      Connection.createSession()
  
  00:02 Create a JMS MessageConsumer
      Session.createConsumer(Destination)
  
  00:03 Initiate a long (1 hour) receive call
      MessageConsumer.receive(3600000)
  
  00:05 After 5 minutes, the TCP/IP socket associated with the JMS
  Connection is closed.  No Connection
  "javax.jms.ExceptionListener" has been configured, so this
  disconnection is silent from the application's perspective.
  
  00:15 After 15 minutes, the application attempts to shut down,
  and expects to interrupt the receiving thread by closing the
  MessageConsumer:
      MessageConsumer.close()
  
  In order to interrupt the receiving thread in the SHARECNV(1)
  configuration, the Connection's 'hconn' must be used to notify
  the queue manager that the receiving thread is to be released.
   As the Connection's 'hconn' was no longer connected to the
  queue manager, this notify message did not reach the queue
  manager.  No exception was returned to the closing thread -
  instead the close() method call completed and the receiving
  thread was still blocked in the receive, for the duration of the
  receive call.
  
  01:03 After 1 hour, the receive call completed and the the
  thread returned.
  
  
  The problem exists for several ways of attempting to interrupt
  the MessageConsumer, including:
  
    MessageConsumer.close()
    Session.close()
    Connection.close()
  

Problem conclusion

• The IBM MQ classes for JMS have been updated such that when this
  scenario is detected, and the notify message fails to be sent to
  the queue manager, the IBM MQ classes for JMS will attempt to
  establish a new connection to the queue manager in order to flow
  the notify request.
  
  Once the notify request has been made, this new connection will
  then be disconnected.
  
  
  If this re-connection attempt fails for some reason, the socket
  associated with the 'hconn' for the JMS Session will then be
  closed.  This closing action will be reported to the receiving
  thread in the form of a JMS Exception, reporting a:
  
    MQRC_CONNECTION_BROKEN
  
  error message.
  
  
  The action of re-connecting to the queue manager to issue this
  notify message is expected to be expensive in terms of the time
  taken to establish a new connection to the queue manager.  This
  may be observed as the call to:
  
    MessageConsumer.close();
  
  taking longer than is typical for your environment.  Therefore
  if your application regularly issues the close() JMS method call
  in order to interrupt long running receive calls, without
  re-establishing the JMS Connection, it is suggested that your
  application also register an ExceptionListener against the
  associated JMS Connection, in order to be notified when the JMS
  Connection is detected to be disconnected from the queue
  manager, and then not continue to perform receive calls against
  associated MessageConsumers without the application closing the
  existing JMS artifacts and creating new ones to initiate further
  receive calls.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v9.0 LTS   9.0.0.7
  v9.1 CD    9.1.3
  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 M/P

• Fixed component ID

  5724H7261

Applicable component levels