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 number
IV69556
Reported component name
WMQ AIX V7
Reported component ID
5724H7221
Reported release
701
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2015-02-16
Closed date
2015-05-19
Last modified date
2015-05-19
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
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSDEZSF","label":"IBM WebSphere MQ Managed File Transfer for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
31 March 2023