IT24782: WebSphere MQ classes for JMS generate FFDC containing probe ID JO136001 when the queue manager they are using stops

APAR status

• Closed as program error.

Error description

• A WebSphere MQ V7.1 classes for JMS application is connecting to
  a queue manager using the CLIENT transport. If the queue manager
  is stopped while the application is still running, the WebSphere
  MQ classes for JMS intermittently throw a JMSException
  containing WebSphere MQ reason code 2195 (MQRC_UNEXPECTED_ERROR)
  and generate an FFDC containing the following information:
  
  **************************************************************
  JMS Common Client First Failure Symptom Report
  
  Source Class :- com.ibm.mq.jmqi.remote.impl.RemoteSession
  Source Method :- receiveMQIFlow(RemoteTls)
  ProbeID :- JO136001
  
  Stack trace -----------
  Stack trace to show the location of the FFST call
   | FFST Location :- java.lang.Exception
   | at
  com.ibm.msg.client.commonservices.trace.Trace.getCurrentPosition
  (Trace.java)
   | at
  com.ibm.msg.client.commonservices.trace.Trace.createFFSTString(T
  race.java:)
   | at
  com.ibm.msg.client.commonservices.trace.Trace.ffstInternal(Trace
  .java)
   | at
  com.ibm.msg.client.commonservices.trace.Trace.ffst(Trace.java)
   | at
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receiveMQIFlow(RemoteS
  ession.java)
      :    :    :    :    :    :    :    :    :    :    :    :
     :    :
  **************************************************************
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects users of:
  
  - The WebSphere MQ classes for Java.
  - The WebSphere MQ classes for JMS.
  - The WebSphere MQ resource adapter.
  
  who have applications that connect to a queue manager using the
  CLIENT transport and WebSphere MQ messaging provider normal
  mode.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  The Java Message Queueing Interface (JMQI) is a component of
  the:
  
  - WebSphere MQ classes for Java.
  - WebSphere MQ classes for JMS.
  - WebSphere MQ resource adapter
  
  that handles all of the communication with a queue manager.
  Whenever an application using either the WebSphere MQ classes
  for Java, classes for JMS or resource adapter calls a method
  that requires an MQ  API call to be flowed to the queue manager,
  then the JMQI will make the MQ API call on behalf of the
  application, and process the response that comes back from the
  queue manager.
  
  If an application connects to a queue manager using:
  
  - The CLIENT transport.
  - And WebSphere MQ messaging provider normal mode.
  
  then the JMQI will send the MQ API call to the queue manager on
  the application thread. It will then use an internal Remote
  Receive Thread to pick up the response.
  
  There is one internal Remote Receive Thread per channel instance
  (or TCP/IP connection, if you prefer to think of channel
  instances in those terms). When the Remote Receive Thread
  receives data from a queue manager, it will either process the
  data itself or pass it off to another thread (either the
  application thread or another internal thread).
  
  Now, when an application connected to a queue manager using:
  
  - The CLIENT transport
  - And WebSphere MQ messaging provider normal mode
  
  then when the queue manager was shut down, it sent two internal
  data flows to the JMQI:
  
  - The first data flow was a notification indicating that the
  queue manager had been stopped.
  - The second data flow was an status event, indicating that the
  channel had been closed.
  
  When the Remote Receive Thread received the notification, it
  started a new internal thread to process it. This internal
  thread informed all of the application threads that were using
  the channel instance associated with the Remote Receive Thread
  that the queue manager is no longer available, which caused any
  MQ API calls that were in progress on the application threads to
  fail.
  
  Next, the Remote Receive Thread picked up the status event, and
  passed it directly on the application threads.
  
  Because the internal thread that was processing the notification
  was running at the same time as the Remote Receive Thread was
  processing the status event, there was a small timing window
  where an application thread, that had issued an MQ API call and
  was waiting for a response, was given the status event before
  the internal thread had notified it that the queue manager was
  no longer running. The application thread was not expecting to
  receive the status event at this time, and threw an exception
  containing WebSphere MQ reason code 2195:
  
  MQRC_UNEXPECTED_ERROR
  
  back to the application, and generated an FFDC. An example of
  the FFDC is shown below:
  
  **************************************************************
  JMS Common Client First Failure Symptom Report
  
  Source Class :-
    com.ibm.mq.jmqi.remote.impl.RemoteSession
  Source Method :- receiveMQIFlow(RemoteTls)
  ProbeID :- JO136001
  
  Stack trace -----------
  Stack trace to show the location of the FFST call
   | FFST Location :- java.lang.Exception
   | at
  com.ibm.msg.client.commonservices.trace.Trace.getCurrentPosition
  (Trace.java)
   | at
  com.ibm.msg.client.commonservices.trace.Trace.createFFSTString(T
  race.java:)
   | at
  com.ibm.msg.client.commonservices.trace.Trace.ffstInternal(Trace
  .java)
   | at
  com.ibm.msg.client.commonservices.trace.Trace.ffst(Trace.java)
   | at
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receiveMQIFlow(RemoteS
  ession.java)
      :    :    :    :    :    :    :    :    :    :    :    :
     :    :
  **************************************************************
  

Problem conclusion

• The JMQI has been updated to ignore any status events that are
  passed to an application thread for processing. This allows the
  application thread to continue waiting for a response to an MQ
  API call.
  
  Once the JMQI has processed the notification asynchronously, the
  application thread will be informed that the queue manager is no
  longer accessible - this causes it to stop waiting, and fail
  with an exception containing an appropriate WebSphere MQ reason
  code, such as 2161:
  
  MQRC_Q_MGR_QUIESCING
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.5       7.5.0.9
  v8.0       8.0.0.11
  v9.0 LTS   9.0.0.5
  
  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

  WMQ WINDOWS V7

• Fixed component ID

  5724H7220

Applicable component levels