IT21642: MQ classes for Java and classes for JMS do not handle MQRC_SECURITY_ERROR correctly when getting messages

APAR status

• Closed as program error.

Error description

• An application using the MQ classes for Java connected to an MQ
  V9 queue manager using the CLIENT transport. The Advanced
  Message Security (AMS) component had been installed on the queue
  manager system. The MQ classes for Java application calls the
  method:
  
    MQQueueManager.accessQueue(String, int)
  
  to open a queue that had an AMS policy defined on it, and then
  calls the method:
  
    MQQueue.get(MQMessage, MQGetMessageOptions)
  
  to get messages from it. The application does not have the
  correct permissions to access the messages on the queue, and
  most of the time the:
  
   MQQueue.get(MQMessage, MQGetMessageOptions)
  
  method throws an MQException containing reason code 2063
  (MQRC_SECURITY_ERROR). Intermittently, though, the method
  incorrectly throws an MQException containing reason code 2033
  (MQRC_NO_MSG_AVAILABLE) even though there are messages on the
  queue.
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects two categories of user:
  
  Category 1:
  -------------
  Users of:
  
  - The IBM MQ V8 classes for Java.
  - The IBM MQ V9 classes for Java.
  
  who have applications that:
  
  - Connect to a queue manager that has the Advanced Message
  Security (AMS) component installed.
  - And call one of the methods:
  
      - MQQueueManager.accessQueue(String, int)
      - MQQueueManager.accessQueue(String, int, String, String
  String)
  
  to access a queue on the queue manager that has an AMS policy
  defined on it.
  - And then call one of the methods shown below:
  
      - MQQueue.get(MQMessage)
      - MQQueue.get(MQMessage, MQGetMessageOptions)
      - MQQueue.get(MQMessage, MQGetMessageOptions, int)
  
  to get messages from the queue, where the application does not
  have permission to get those message.
  
  Category 2:
  -------------
  Users of:
  
  - The IBM MQ V8 classes for JMS.
  - The IBM MQ V9 classes for JMS.
  
  - The IBM MQ V8 resource adapter.
  - The IBM MQ V9 resource adapter.
  
  - The WebSphere Application Server V9 IBM MQ messaging provider.
  
  who have applications that:
  
  - Connect to a queue manager that has the Advanced Message
  Security (AMS) component installed, using IBM MQ messaging
  provider normal mode or normal mode with restrictions.
  - And call one of the methods:
  
      - MessageConsumer.receive()
  	- MessageConsumer.receive(long)
  	- MessageConsumer.receiveNoWait()
  	
  to get messages from a JMS destination hosted on the queue
  manager, where the underlying queue or topic for the destination
  has an AMS policy defined which prevents the application from
  getting messages from it.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When an MQ classes for Java application calls one of the
  methods:
  
  - MQQueue.get(MQMessage)
  - MQQueue.get(MQMessage, MQGetMessageOptions)
  - MQQueue.get(MQMessage, MQGetMessageOptions, int)
  
  to get a message from a queue hosted on an MQ queue manager, the
  MQ classes for Java will do the following on the application
  thread:
  
  - Send a request to the queue manager, asking for a message.
  - Either wait indefinitely for a response from the queue
  manager, if the MQGetMessageOptions object passed in to the
  method did not specify a wait interval.
  - Or wait for the specified period of time for the queue manager
  to response before timing out.
  
  Similarly, if an MQ classes for JMS application connects to an
  MQ queue manager using either IBM MQ messaging provider normal
  mode or normal mode with restrictions, and calls one of the
  following methods:
  
  - MessageConsumer.receive()
  - MessageConsumer.receive(long)
  - MessageConsumer.receiveNoWait()
  
  to get a message from a JMS destination hosted on that MQ queue
  manager, the MQ classes for JMS send a request to the queue
  manager, asking for a message, and then:
  
  - Either wait indefinitely for a response from the queue
  manager, if the application called the method
  MessageConsumer.receive().
  - Or wait for the time period specified by the application for a
  response from the queue manager, if the application called the
  method MessageConsumer.receive(long).
  - Or wait for an immediate response from the queue manager, if
  the application called MessageConsumer.receiveNoWait().
  
  The response from the queue manager is received on an internal
  Remote Receive Thread. When this thread receives the response,
  it checks to see what type of response the queue manager has
  sent. If the response is a message, then the Remote Receive
  Thread passes the message to the application thread. The MQ
  classes for Java or MQ classes for JMS running on the
  application thread then pass the message back to the application
  for processing.
  
  If there has been an issue with the attempt to get a message
  (such as a security error), then the queue manager sends back a
  notification, along with an appropriate reason code, rather than
  a message. The Remote Receive Thread receives the notification
  and sets some internal state to indicate that the attempt to get
  a message failed. The MQ classes for Java or MQ classes for JMS
  running on the application thread are made aware of the state
  change and throw an exception back to the application.
  
  If the Remote Receive Thread changed the internal state a few
  milliseconds before the MQ classes for Java or MQ classes for
  JMS running on the application thread checked the state, then it
  was possible for the MQ classes for Java or MQ classes for JMS
  running on the application thread to see the old value rather
  than the updated one. This meant that, if the Remote Receive
  Thread had changed the internal state to indicate that a
  security error had occurred, then the application thread would
  incorrectly think that the attempt to get a message failed due
  to reason code 2033 (MQRC_NO_MSG_AVAILABLE) rather than reason
  code 2063 (MQRC_SECURITY_ERROR). If this happened:
  
  - The MQ classes for Java would incorrectly throw an MQException
  containing reason code 2033 (MQRC_NO_MSG_AVAILABLE) back to the
  application.
  - The MQ classes for JMS methods:
  
      - MessageConsumer.receive()
      - MessageConsumer.receive(long)
      - MessageConsumer.receiveNoWait()
  
  would return null back to the application, indicating that there
  was no message on the destination.
  

Problem conclusion

• The way the MQ classes for Java or MQ classes for JMS store the
  internal state information about whether an attempt to get a
  message was successful or failed has been changed to ensure that
  the application thread always reads the most up-to-date value.
  This means that:
  
  - If an application using the MQ classes for Java calls one of
  the methods:
  
      - MQQueue.get(MQMessage)
      - MQQueue.get(MQMessage, MQGetMessageOptions)
      - MQQueue.get(MQMessage, MQGetMessageOptions, int)
  
  to get a message, and is unable to do so due to a security
  error, an MQException containing reason code 2063
  (MQRC_SECURITY_ERROR) will be thrown back to the application.
  
  - If an application that is using the MQ classes for JMS calls
  one of the following methods:
  
      - MessageConsumer.receive()
      - MessageConsumer.receive(long)
      - MessageConsumer.receiveNoWait()
  
  to get a message from a JMS destination, and is unable to do so
  due to a security error, a JMSException will be thrown back to
  the application. The JMSException will contain a linked
  exception containing reason code 2063 (MQRC_SECURITY_ERROR)
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v8.0       8.0.0.8
  v9.0 CD    9.0.4
  v9.0 LTS   9.0.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

  WMQ BASE MULTIP

• Fixed component ID

  5724H7251

Applicable component levels

• R800 PSY

     UP