APAR status
Closed as program error.
Error description
If a receiver channel is running with PipeLineLength=2, and is stopped either by an administrator or an Adopt MCA operation from a new channel instance, the channel might become stuck in "stopping" status indefinitely. If the stop channel was issued automatically as part of an Adopt MCA operation, and the configured AdoptNewMCATimeout interval expires, the attempt to adopt fails with AMQ9514E (channel in use) written to the RCVR sides error log. The corresponding sender channel reports AMQ9558E (remote channel unavailable) in its queue manager's error log. If this scenario is encountered, the channel will remain in stopping status will remain while its underlying TCP connection connected, and will be resolved if this TCP connection is closed, for example if terminated by a firewall, or by MQ HBINT logic.
Local fix
The issue can be mitigated by preventing TCP connections from running indefinitely, for example by setting the MQ channel HBINT to a value greater than 0. If such configuration is not possible, remove PipeLineLength=2 from qm.ini to revert to its default value of 1. Alternatively, set/export the environment variable MQPIPELINELENGTH=1 in the environment used to start the queue manager.
Problem summary
**************************************************************** USERS AFFECTED: Users of receiver channels with PipeLineLength=2 set. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: When PipeLineLength=2 is set, a compatible channel's workload is managed across two threads instead of one. A timing window existed when stopping a receiver channel running in this mode whereby the channel process job monitor could notify one of the channel's threads while it was waiting for a lock being held by the other thread. If the other thread did not yield the lock (for example, if in an indefinite socket read), the request would not be processed by the waiting thread and the channel would not stop.
Problem conclusion
The queue manager's channel job monitor logic has been modified so that if the channel being stopped is a RCVR channel with PipeLineLength=2, both threads are notified of the channel stop request to avoid this timing window. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v9.x CD 9.2.5 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
IT38623
Reported component name
MQ BASE V9.2
Reported component ID
5724H7281
Reported release
922
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2021-10-06
Closed date
2022-01-11
Last modified date
2022-01-13
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
MQ BASE V9.2
Fixed component ID
5724H7281
Applicable component levels
[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"922"}]
Document Information
Modified date:
14 January 2022