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

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 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