IV69556: WMQ-RA ACTIVATION SPECIFICATION STARTUP RECONNECTION RETRY FUNCTION RESULTS IN THE USE OF NON-TRANSACTED MDBS

APAR status

• Closed as program error.

Error description

• Messages are lost when WebSphere Application Server (WAS) is
  restarted and the queue manager is down.
  
  The activation specification is configured to start with the
  application server. The message driven bean (MDB) does not
  immediately start because the queue manager is unavailable on
  application server startup.
  
  However the application server JVM is configured with the
  following activation specification startup reconnection
  properties:
  
  com.ibm.mq.jms.tuning.startupReconnectionRetryCount =
          2147483647
  
  com.ibm.mq.jms.tuning.startupReconnectionRetryInterval =
          10000
  
  Once the queue manager becomes available, the activation
  specification is able to start and begin processing messages.
  The MDB is rolled back, but the message is not rolled back to
  the source queue, resulting in its loss.
  
  Warning messages in the Systemout.log file to show that the
  activation specification did not startup immediately include:
  
  CWSJY0003W: MQJCA4021: Trying to reconnect ActivationSpec
  'javax.jms.Queue:jms/Queue1'
  CWSJY0003W: MQJCA4022: Waiting for '10,000' milliseconds before
  reconnecting
  CWSJY0003W: MQJCA4018: MessageEndpoint afterDelivery() call
  failed with: 'afterDelivery failure'
  
  
  The problem can be recreated by the following method:
  
  (1) Queue manager is stopped/unavailable
  
  (2) WAS is started, containing an MDB which is driven off an MQ
   queue on the queue manager which is not available.
  
  (3) The Activation Specification for the MDB is configured to
   startup with the application server. However the queue
   manager is unavailable, so the Activation Specification
   cannot start.
  
  (4) The Activation Specification is unable to start, so goes
   into the retry mode of operation, and retries every 10
   seconds.
  
  (5) The queue manager is brought online, and the Activation
   Specification connects, and drives the MDB.
  
  (6) The MDB is set to rollback, and completes processing. WAS
   then commits the message which drove the MDB, and rolls
   back any work which was done during the MDB invocation
   (for example the updating of a database).
  

Local fix

• Disable retry start for the activation specification, or ensure
  that the queue manager is enabled when the activation
  specification attempts to start, such that the startup retry
  functionality is not utilised at startup.
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects all users of the WebSphere MQ Resource
  Adapter, who are making use of the 'Startup Reconnection Retry
  Count' function (added by APAR IZ76343 in WMQ-RA 7.0.1.3)
  through the use of the JVM property:
  
    com.ibm.mq.jms.tuning.startupReconnectionRetryCount
  
  
  The WMQ-RA is only affected by this problem if the resource (the
  queue manager) is unavailable when the endpoint is started, such
  that this start retry function is utilised.
  
  It does not affect users of the WMQ-RA who are using the retry
  reconnection function, which re-connects the WMQ-RA to the queue
  manager if the connection is dropped. Only the
  startup-reconnection function is affected.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  If the queue manager was not available during endpoint
  activation (eg. the point where an activation specification is
  starting up, such as when an application server starts up),
  function added to the WMQ-RA at version 7.0.1.3 by APAR IZ76343
  allows an JVM system property to be set which controls the
  startup reconnection behaviour of the endpoint, this property
  being:
  
    com.ibm.mq.jms.tuning.startupReconnectionRetryCount
  
  If this is defined with an integer value which is not '0', then
  the endpoint will attempt to reconnect to the queue manager at
  periodic intervals, configured by the property:
  
    com.ibm.mq.jms.tuning.startupReconnectionRetryInterval
  
  which takes as an integer value for the time in milliseconds
  between reconnection attempts.
  
  
  Once the endpoint does successfully reconnect to the queue
  manager and a suitable message is found to drive the MDB, the
  JMS Session which was created by the WMQ-RA was always of the
  non-transacted type (non-XA), irrespective of the transactional
  scope of the MDB.
  
  As a result of this, if the MDB was to rollback for some reason,
  any work which was done with other resources would be rolled
  back by the transaction manager. However the message which
  caused the MDB to be driven would be committed and not rolled
  back, resulting in the message being lost.
  

Problem conclusion

• The WMQ-RA has been updated to ensure that the appropriate type
  of transacted JMS Session is used when creating the Session for
  an endpoint which started using the startup reconnection retry
  mechanism.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.0       7.0.1.14
  
  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 is sysrouted FROM one or more of the following:

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

  PI41156

Fix information

• Fixed component name

  WMQ AIX V7

• Fixed component ID

  5724H7221

Applicable component levels

• R701 PSY

     UP