search

ibm-messaging / mq-jms-spring

Components to assist MQ JMS integration with Spring frameworks
Apache License 2.0
186 stars 102 forks source link

An MQ JMS application deadlocks when multiple threads compare JMS destinations #78

Closed dipint closed 1 year ago

dipint commented 2 years ago

Problem Statement:

An MQ classes for JMS application deadlocks when two (or more) threads compare JMS Destination objects in different orders.

This is the same issue which is fixed in the APAR IT27638. But it is still happening on com.ibm.mq.allclient versions 9.1.1.0 and higher. Looks like the fix is not ported to the latest versions of com.ibm.mq.allclient.

Putting the same description as it is in the APAR -

Consider two threads having access to the same two instances of the class com.ibm.mq.jms.MQQueue identified by the variables mqQueue1 and mqQueue2. If the first thread invokes the equals(Object) method on mqQueue1 passing in mqQueue2 as the argument:

mqQueue1.equals(mqQueue2)

while the second thread simultaneously does the opposite:

mqQueue2.equals(mqQueue1)

then a deadlock can occur. A Javacore of the JVM shows two threads having synchronized on a Map belonging to one of the MQQueue objects and blocked while attempting to access the Map belonging to the other MQQueue object. For example:

"thread-1" - Thread t@1
   java.lang.Thread.State: BLOCKED
    at java.base@11.0.6/java.util.Collections$SynchronizedMap.get(Collections.java:2594)
    - waiting to lock <616a96fe> (a java.util.Collections$SynchronizedMap) owned by "thread-2" t@2
    at com.ibm.msg.client.jms.internal.JmsPropertyContextImpl.getObjectProperty(JmsPropertyContextImpl.java:582)
    at com.ibm.msg.client.jms.internal.JmsReadablePropertyContextImpl.getStringProperty(JmsReadablePropertyContextImpl.java:343)
    at com.ibm.msg.client.jms.internal.JmsReadablePropertyContextImpl.compareContexts(JmsReadablePropertyContextImpl.java:908)
    - locked <116e7225> (a java.util.Collections$SynchronizedMap)
    at com.ibm.msg.client.jms.admin.JmsDestinationImpl.equals(JmsDestinationImpl.java:854)
"thread-2" - Thread t@2
   java.lang.Thread.State: BLOCKED
    at java.base@11.0.6/java.util.Collections$SynchronizedMap.get(Collections.java:2594)
    - waiting to lock <116e7225> (a java.util.Collections$SynchronizedMap) owned by "thread-1" t@1
    at com.ibm.msg.client.jms.internal.JmsPropertyContextImpl.getObjectProperty(JmsPropertyContextImpl.java:582)
    at com.ibm.msg.client.jms.internal.JmsReadablePropertyContextImpl.getStringProperty(JmsReadablePropertyContextImpl.java:343)
    at com.ibm.msg.client.jms.internal.JmsReadablePropertyContextImpl.compareContexts(JmsReadablePropertyContextImpl.java:908)
    - locked <616a96fe> (a java.util.Collections$SynchronizedMap)
    at com.ibm.msg.client.jms.admin.JmsDestinationImpl.equals(JmsDestinationImpl.java:854)
ibmmqmet commented 2 years ago

This does sound like the same problem as in the APAR, even though the associated fix appears to be already in the 9.2 stream. But there's nothing that can be done in this repo. You need to open a support case with IBM to get problems in the allclient jar investigated.

dipint commented 2 years ago

Yes, it is the same problem as in the APAR. It is fixed on allclient jar versions from 9.1.0.2 to 9.1.0.10, but starting from 9.1.1.0, the fix is not there (even it is not there in 9.1.2). I will open a support case with IBM. Thank you.