IBM Support

IZ90144: A JMS LISTENER PORT STOPS PROCESSING MESSAGES AFTER WAS UPGRADE FROM V6 TO V7

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A JMS listener port stops processing messages after a WebSphere
    Application Server (WAS) upgrade from V6 to V7, leading to a
    build up of messages on the queue. Listener port appears as
    'Running' in the WAS Admin Console, and there are no exceptions
    reported in SystemOut.log.
    

Local fix

  • 1. Restart listener or a WAS application server
    2. Disable ReadAhead feature in WAS V7.
       Please set a ReadAhead flag to 'as queue definition' for a
       destination in WAS Admin Console and restart the application
       server.
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of the WebSphere MQ classes for
    Java/JMS who are using the Read Ahead functionality provided
    within version WebSphere MQ v7.
    
    This includes users of the WebSphere MQ Resource Adapter v7,
    such as the WebSphere Application Server v7, or WebSphere
    Application Server v6 which is configured to use the v7
    WebSphere MQ classes for JMS.
    
    Platforms affected:
    All Distributed (iSeries, all Unix and Windows) +Java
    ****************************************************************
    PROBLEM SUMMARY:
    WebSphere MQ v7 introduced new functionality known as 'Read
    Ahead'.  When working with non-persistent messages, this
    function permits the client classes to download messages from
    the queue before the client application requests the message.
    This can result in a more efficient system, where the message
    has already been retrieved over the client (TCP) connection by
    the time the client is ready to consume it.
    
    The Read Ahead functionality can also be used with
    non-destructive gets with persistent messages, such as when
    browsing a queue.  In the application server environment, this
    can be used by the activation specification or listener port
    browsing threads, when using the default Application Server
    Facilities (ASF) functionality of the WebSphere MQ Resource
    Adapter.
    
    The use of Read Ahead is configured as a client side queue
    definition setting.  For example, when using the WebSphere
    Application Server, in the Administration Console on the
    queue definition advanced properties:
    
    Resources -> JMS -> Queues -> [queue] > Advanced properties
    
    the setting is configured by the option titled:
    
    "Read ahead, and cache, non-persistent messages for consumers"
    
    The default setting is "As per queue definition", which means
    the value set on the queue on the queue manager is used, for
    the queue property "DEFREADA", which defaults to "NO".
    
    Note that when migrating WebSphere Application Server from v6
    to v7, the default client side value is set to "YES", which
    results in systems using Read Ahead during the process of
    consumption of Message Driven Beans (MDBs) which are being
    triggered by messages from a v7 WebSphere MQ queue.  This
    migration issue is discussed further in the following Technote:
    
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg21448387
    
    
    The problem described by this APAR concerns the use of Read
    Ahead when using a WebSphere MQ classes for Java/JMS based
    client, including that used by an application server when using
    the WebSphere MQ Resource Adapter.
    
    When such a system was using Read Ahead, a defect in the
    threading model used by the WebSphere MQ Java classes resulted
    in the client losing track of the amount of data it had
    requested, received and processed from the Read Ahead local
    caching mechanism.  The problem was typically observed when
    the system was put under load with many applicable messages on
    the WebSphere MQ queue, which resulted in the maximum number
    of server sessions being driven simultaneously in the
    application server environment.
    
    When the problem was encountered, the only external observable
    event was that the MDB would stop consuming messages, despite
    there being applicable messages available for consumption on
    the queue.  In a system where messages continued to flow onto
    the source queue, this would result in a build up of messages.
    
    No messages were output into application server logs, and the
    Administration Console showed that the application/Listener
    Port were still running.
    
    Restarting the application (in the case where an Activation
    Specification was being used to drive the MDB), or restarting
    the Listener Port would result in messages once again being
    consumed from the queue.
    
    The frequency of the problem depended on the system load and
    message throughput.  Generally customers observed the issue
    after the system had been running for a few days.  In a test
    environment, the problem could be recreated within a few
    minutes of starting the application server.
    
    A work around for the problem is to disable Read Ahead.  This
    work around has no impact on the consuming application, other
    than a potential drop in performance in heavily loaded
    environments where the time taken to transfer message data from
    the queue manager to the client is the limiting factor.
    

Problem conclusion

  • The WebSphere MQ classes for JMS have been modified to address
    the defect in the threading model, such that
    thread locking now prevents multiple threads from simultaneously
    attempting to update the key variables used to control the
    requests for data from the queue manager.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v7.0       7.0.1.6
    
    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

    IZ90144

  • Reported component name

    WMQ AIX V7

  • Reported component ID

    5724H7221

  • Reported release

    700

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-12-03

  • Closed date

    2011-03-10

  • Last modified date

    2013-10-29

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    PM42810

Fix information

  • Fixed component name

    WMQ AIX V7

  • Fixed component ID

    5724H7221

Applicable component levels

  • R700 PSY

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCPQ63","label":"APAR \/ Maintenance"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
29 October 2013