IC82912: WEBSPHERE MQ EVERYPLACE V2.0.2 (MQE): SYSTEM.TRANSACTION.QUEUE GROWS AFTER SOME PERIOD OF TIME TO MBS IN SIZE.

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Tivoli Directory Integrator's 'MQePassword Store Connector'
    runs in iterate (read) mode. When it is iterating we see that
    the message file in the SYSTEM.TRANSACTION.QUEUE is
    continually overwritten and grows by 40kb on each rewrite.
    So this file grows after some period of time to MBs in size.
    .
    For getting messages from a queue, the WebSphere MQ
    EveryPlace V2.0.2 (MQE) JMS uses the transaction mechanism
    present in MQe in order to work through the various
    acknowledgment modes. This mechanism uses a transaction queue,
    even when a session is non-transacted.
    .
    Messages are found in the SYSTEM.TRANSACTION.QUEUE which are
    log messages which are saved for recovery purposes.
    .
    Since a receive call with 0 timeout is being called in the
    problem reported in this APAR, the thread keeps trying
    indefinitely until a message is received.
    Since there are no messages in the queue, this attempt
    continues indefinitely.
    Because a receive or a get in MQe is worked under transactions,
    every activity is logged and stored inside a message in the
    SYSTEM.TRANSACTION.QUEUE.
    The log messages keep appending until there is a message
    received.
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    All users of MQe version 2.0.2.16 and below.
    
    Platforms affected:
    AIX,HP-UX (Itanium),Linux (Power),Linux (x86),Solaris (SPARC),
    Windows
    
    ****************************************************************
    PROBLEM SUMMARY:
    MQe JMS was designed in a such a way that transactions were used
    on every get operation whether it was under a transacted or
    non-transacted session. This was done in order to work with the
    various acknowledgement modes in JMS. When under transaction a
    log is written for every as a message in a system defined queue
    SYSTEM.TRANSACTION.QUEUE for recovery purposes. After receiving
    the acknowledgement the logs were deleted.
    
    In case of a continuous get operation from an empty queue the
    logs were getting written indefinitely and since there were no
    acknowledgement for empty messages, these logs grew indefinitely
    in size.
    

Problem conclusion

  • In case of an empty queue where the get operation returns a null
    we need not log the messages in a transaction log because this
    does not server any purpose in recovery mechanisms also. Hence
    the problem of indefinite logging in the transaction queue was
    solved for this particular case.
    ---------------------------------------------------------------
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC82912

  • Reported component name

    WMQ EVERYPLACE

  • Reported component ID

    5724C7700

  • Reported release

    200

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-04-25

  • Closed date

    2012-05-30

  • Last modified date

    2012-05-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 EVERYPLACE

  • Fixed component ID

    5724C7700

Applicable component levels

  • R200 PSY

       UP



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere MQ Everyplace
General

Software version:

2.0

Reference #:

IC82912

Modified date:

2012-05-30

Translate my page

Machine Translation

Content navigation