IBM Support

IV66241: JMSWMQ1017 "NON-LOCAL MQ QUEUE NOT VALID" ERROR MESSAGE ISSUED WHEN IT IS USED AUTO-RECONNECT WITH TEMPORARY QUEUES

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • An error is issued when it uses JMS and WMQ Ver.7.1.0. If it is
    used auto-reconnect facility, the following error is received
    when an application loses connection to a QM and it reconnects
    back to other different QM:
    
    JMSWMQ1017: non-local MQ queue 'MQ.QM.TEMP' not valid for
    receiving or browsing.] [JMSWMQ1017] [The MQ queue is not able
    to be opened, as it not local to the connected Queue Manager. ]
    [Connect to the Queue Manager for which this MQ Queue resides
    locally.] [{XMSC_DESTINATION_NAME=MQ.QM.TEMP}]
    
    The MQ.QM.TEMP model queue is correctly defined in both Queue
    Managers. The model queue is defined with QSGDISP(QMGR) in both
    Queue Managers.
    
    Error is because a JMS Connection object stores some information
    about the queue manager that they had originally connected to.
    
    This information is then used when an application creates a JMS
    Session from a JMS Connection, and then calls:
    
      Session.createTemporaryQueue()
    
    However, if automatic reconnection takes place, the queue
    manager name that had previously been stored is not updated.
    This means that, if an application calls:
    
      Session.createTemporaryQueue()
    
    after reconnection has occurred, the WebSphere MQ classes for
    JMS incorrectly opens the queue specifying the wrong queue
    manager name.
    
    Although this method call works, it leads to issues when the
    application then tries to use that temporary queue.
    

Local fix

  • No Local Fix
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of:
    
    - The WebSphere MQ V7.1 classes for JMS
    - The WebSphere MQ V7.5 classes for JMS
    - The WebSphere MQ V8 classes for JMS
    
    who have JMS applications that use JMS Connection Factory which
    has the following properties set:
    
    CLIENTRECONNECTOPTIONS : ANY
    CONNECTIONNAMELIST : a list of hostnames and ports>
    QMANAGER : ""
    
    and make use of automatic client reconnection.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    In order to create a temporary queue, an application calls the
    method Session.createTemporaryQueue(). While processing this
    method call, the JMS Session delegates the call to the JMS
    Connection that created it. The reason for this is that
    temporary queues are "owned" by a JMS Connection, even though
    they are created by JMS Sessions, as stated in section
    
    
    If an application creates a JMS Connection followed by a JMS
    Session, and calls QueueSession.createTemporaryQueue(), the
    WebSphere MQ classes for JMS build an MQOD Object Descriptor
    containing the following information:
    
    - The name of the queue manager that the JMS application is
    connected to (the ObjectQMgrName field)
    - The name of the model queue on the queue manager that the
    temporary queue will be based on (the ObjectName field)
    - The prefix that will be used to name the temporary queue (the
    DynamicQName field)
    
    An MQOPEN call is then made to open the temporary queue.
    
    Now, when a JMS Connection is created, it stores the name of the
    queue manager that it has connected to in a local variable.
    
    It was this "resolved queue manager name" that was then stored
    in the MQOD Object Descriptor passed to the queue manager as
    part of the MQOPEN.
    
    If automatic client reconnection had occurred between a JMS
    Connection being created and an application calling
    QueueSession.createTemporaryQueue(), then the "resolved queue
    manager name" stored in the JMS Connection would be incorrect.
    It would be set to the name of the queue manager that the
    application had originally connected to, rather than the queue
    manager the JMS Connection was currently connected to.
    
    For JMS applications that had reconnected to stand-alone queue
    managers, the call to QueueSession.createTemporaryQueue() would
    fail with a JMSException containing the following message:
    
    JMSWMQ2008: Failed to open MQ queue ''. JMS attempted to perform
    an MQOPEN, but WebSphere MQ reported an error. Use the linked
    exception to determine the cause of this error. Check that the
    specified queue and queue manager are defined correctly.
        : : : : : : : : : : : : : : : : : :
    Linked Exception com.ibm.mq.MQException: JMSCMQ0001: WebSphere
    MQ call failed with compcode '2' ('MQCC_FAILED') reason '2087'
    ('MQRC_UNKNOWN_REMOTE_Q_MGR').
    
    The reason for the JMSException was because the WebSphere MQ
    classes for JMS had issued an MQOPEN call to open the model
    queue on a different queue manager to the one that the
    application was connected to, and there was no path from the
    current queue manager to the original queue manager in the
    underlying WebSphere MQ infrastructure.
    
    
    If a JMS application had reconnected to a queue manager that was
    part of a WebSphere MQ network or a Queue Sharing Group, there
    was a path in the WebSphere MQ infrastructure from the current
    queue manager to the original queue manager and the specified
    model queue existed on the current queue manager, then the call
    to QueueSession.createTemporaryQueue() would work successfully.
    However, when the application then tried to create a
    QueueReceiver for that temporary queue, the call to
    QueueSession.createQueueReceiver(Queue) would try to reopen the
    queue to get messages from it - this would fail with a
    JMSException containing the message shown below:
    
    JMSWMQ1017: non-local MQ queue '' not valid for receiving or
    browsing. The MQ queue is not able to be opened, as it is not
    local to the connected Queue Manager. Connect to the Queue
    Manager for which this MQ Queue resides locally.
        : : : : : : : : : : : : : : : : : :
    Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call
    failed with compcode '2' ('MQCC_FAILED') reason '2045'
    ('MQRC_OPTION_NOT_VALID_FOR_TYPE').
    
    The WebSphere MQ classes for JMS had actually opened a local
    definition (on the queue manager that it was currently connected
    to) of a remote model queue (hosted on the original queue
    manager). It is not possible to open a remote queue to get
    messages from it, and so a JMSException containing WebSphere MQ
    Reason Code 2045 was generated.
    

Problem conclusion

  • The WebSphere MQ classes for JMS have been updated to ensure
    that, whenever an application calls the method
    Session.createTemporaryQueue(), the ObjectQMgrName field in the
    MQOD Object Descriptor is left blank. This ensures that the
    temporary queue is created on the queue manager that the
    application is currently connected to.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v7.1       7.1.0.7
    v7.5       7.5.0.6
    v8.0       8.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

    IV66241

  • Reported component name

    WMQ LIN X86 V7

  • Reported component ID

    5724H7224

  • Reported release

    710

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-10-24

  • Closed date

    2015-02-27

  • Last modified date

    2015-02-27

  • 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 LIN X86 V7

  • Fixed component ID

    5724H7224

Applicable component levels

  • R710 PSY

       UP

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSFKSJ","label":"WebSphere MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.1"}]

Document Information

Modified date:
08 March 2021