Fixes are available
APAR status
Closed as program error.
Error description
WMQ V7 JMS application hangs, and there are no FFSTs or exceptions issued. Javacore will show a deadlock between two threads: consumer closing thread: Owns Monitor Lock on java/lang/Object@0x00C5A438/0x00C5A444 at java/lang/Object.wait(Native Method) at java/lang/Object.wait(Object.java:167) at com/ibm/mq/jmqi/remote/internal/RemoteHconn. waitOnDispatchEvent(RemoteHconn.java:677) at com/ibm/mq/jmqi/remote/internal/RemoteHconn. dispatchThreadExchange(RemoteHconn.java:721) at com/ibm/mq/jmqi/remote/internal/RemoteFAP. MQCTL(RemoteFAP.java:2372) at com/ibm/msg/client/wmq/internal/WMQConsumerOwnerShadow. suspendAsyncService(WMQConsumerOwnerShadow.java:698) at com/ibm/msg/client/wmq/internal/WMQSession. suspendAsyncService(WMQSession.java:1605) at com/ibm/msg/client/wmq/internal/WMQConsumerShadow. close(WMQConsumerShadow.java:285) at com/ibm/msg/client/wmq/internal/WMQMessageConsumer. close(WMQMessageConsumer.java:379) at com/ibm/msg/client/jms/internal/JmsMessageConsumerImpl. close(JmsMessageConsumerImpl.java:257) at com/ibm/msg/client/jms/internal/JmsMessageConsumerImpl. close(JmsMessageConsumerImpl.java:183) at com/ibm/mq/jms/MQQueueReceiver.close(MQQueueReceiver.java:80) and the MessageConsumerThread: Waiting for Monitor Lock on java/lang/Object@0x00C5A438/0x00C5A444 at com/ibm/msg/client/jms/internal/JmsSessionImpl. rollback(JmsSessionImpl.java:1640) at com/ibm/mq/jms/MQSession.rollback(MQSession.java:842) at test/testcases/CloseTest$1.onMessage(CloseTest.java:83) at com/ibm/mq/jms/MQMessageConsumer$FacadeMessageListener. onMessage(MQMessageConsumer.java:399) at com/ibm/msg/client/jms/internal/ JmsMessageConsumerImpl$JmsProviderMessageListener. onMessage(JmsMessageConsumerImpl.java:940) at com/ibm/msg/client/wmq/internal/WMQAsyncConsumerShadow. honourNoLocal(WMQAsyncConsumerShadow.java:565) at com/ibm/msg/client/wmq/internal/WMQAsyncConsumerShadow. consumer(WMQAsyncConsumerShadow.java:399) at com/ibm/mq/jmqi/remote/internal/RemoteAsyncConsume. driveConsumer(RemoteAsyncConsume.java:1526) at com/ibm/mq/jmqi/remote/internal/RemoteAsyncConsume. checkTxnMsg(RemoteAsyncConsume.java:1198) at com/ibm/mq/jmqi/remote/internal/RemoteDispatchThread. run(RemoteDispatchThread.java:300) at com/ibm/msg/client/commonservices/workqueue/WorkQueueItem. runTask(WorkQueueItem.java:209) at com/ibm/msg/client/commonservices/workqueue/ SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100) at com/ibm/msg/client/commonservices/workqueue/WorkQueueItem. run(WorkQueueItem.java:224) at com/ibm/msg/client/commonservices/workqueue/WorkQueueManager. runWorkQueueItem(WorkQueueManager.java:298) at com/ibm/msg/client/commonservices/j2se/workqueue/ WorkQueueManagerImplementation$ThreadPoolWorker. run(WorkQueueManagerImplementation.java:1220)
Local fix
Problem summary
**************************************************************** USERS AFFECTED: This issue affects users of the WebSphere MQ V7 classes for JMS that make JMS method calls from within a MessageListener, and that attempt to close the owning MessageConsumer while the MessageListener is processing a message. Platforms affected: All Distributed (iSeries, all Unix and Windows) +Java +Java zOS **************************************************************** PROBLEM SUMMARY: The problem can arise if a call is made within a MessageListener that requires communication with the queue manager (for example calling Session.rollback()), but at the same time, another thread attempts to close the owning MessageConsumer (either directly or by closing the owning Session or Connection). A deadlock can occur as the close() and rollback() calls are serialized, if the close() call begins before the rollback() the rollback() is blocked until the close() completes. However, as per the JMS specification, the close() call will block until all message processing (including that in the MessageListener) has returned. However, the MessageListener cannot return until the rollback() has completed, hence a deadlock results.
Problem conclusion
New locking was implemented to separate out synchronous API calls from asynchronous serialization. These changes allow the MessageListener to continue making JMS API calls while the closing thread is blocked, and then to return to the queue manager, allowing the closing thread to complete. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: v7.0 Platform Fix Pack 7.0.1.7 -------- -------------------- Windows U200333 AIX U843721 HP-UX (PA-RISC) U844089 HP-UX (Itanium) U844094 Solaris (SPARC) U844090 Solaris (x86-64) U844096 iSeries tbc_p700_0_1_7 Linux (x86) U844091 Linux (x86-64) U844095 Linux (zSeries) U844092 Linux (Power) U844093 zOS 7.0.1.7 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
IV00757
Reported component name
WMQ AIX V7
Reported component ID
5724H7221
Reported release
700
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2011-05-20
Closed date
2011-09-15
Last modified date
2013-12-06
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 AIX V7
Fixed component ID
5724H7221
Applicable component levels
R700 PSY
UP
[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSFKSJ","label":"WebSphere MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0"}]
Document Information
Modified date:
27 September 2021