IBM Support

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

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

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 number

    IT21642

  • Reported component name

    WMQ BASE MULTIP

  • Reported component ID

    5724H7251

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2017-07-31

  • Closed date

    2017-08-24

  • Last modified date

    2017-08-30

  • 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

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

Document Information

Modified date:
30 August 2017