The error you are seeing indicates that the application was doing some work inside of a transaction (also known as an MQ syncpoint) at the time it was reconnected, and then it tried to commit that transaction some time later. Because of the reconnection, the transaction would have been rolled back and so the attempt to commit it failed with the MQRC_BACKED_OUT reason code. This is expected behaviour.
Based on what you've said, it sounds like the application is closing everything down when it gets the exception which is why the handles are disappearing. If that's right, then it would need to be modified so that if it gets an exception, it closes everything down and recreates the Jakarta Messaging objects (such as Message Producers and Message Consumers) it was using before continuing. Any messages that were being processed when the reconnection occurred would have been rolled back, so the application would need to reprocess them.
Another option would be to change the application to not use transactions - that would prevent the error from occurring as the application would not have to commit them. However, it does run the risk of message loss when a reconnection event occurs, which might not be what you want!
I hope this helps! If you have any questions on this, let me know.
Original Message:
Sent: Mon September 22, 2025 02:53 AM
From: madhu ram
Subject: Issue with Reconnect
Thank you for your response, Morag.
I executed the following commands:
After the reconnection, the handles are available. However, after a message exchange, the handles(open input count) disappears .
I see the below error in my java application log
: Commit failed, closing JMS context for ext: JMSCMQ0002: The method 'MQCMIT' failed.
com.ibm.msg.client.jakarta.jms.DetailedTransactionRolledBackRuntimeException: JMSCMQ0002: The method 'MQCMIT' failed.
An IBM MQ call failed.
Please see the linked exception for more information.
at com.ibm.msg.client.jakarta.jms.DetailedTransactionRolledBackException.getUnchecked(DetailedTransactionRolledBackException.java:274)
at com.ibm.msg.client.jakarta.jms.internal.JmsErrorUtils.convertJMSException(JmsErrorUtils.java:173)
at com.ibm.msg.client.jakarta.jms.internal.JmsContextImpl.commit(JmsContextImpl.java:279)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2003' ('MQRC_BACKED_OUT').
at com.ibm.msg.client.jakarta.wmq.common.internal.Reason.createException(Reason.java:203)
at com.ibm.msg.client.jakarta.wmq.common.internal.Reason.createException(Reason.java:253)
at com.ibm.msg.client.jakarta.wmq.internal.WMQSession.syncpoint(WMQSession.java:1994)
at com.ibm.msg.client.jakarta.wmq.internal.WMQSession.commit(WMQSession.java:872)
at com.ibm.msg.client.jakarta.jms.internal.JmsSessionImpl.commitTransaction(JmsSessionImpl.java:2858)
at com.ibm.msg.client.jakarta.jms.internal.JmsSessionImpl.commit(JmsSessionImpl.java:754)
at com.ibm.msg.client.jakarta.jms.internal.JmsContextImpl$SessionWrapper.commit(JmsContextImpl.java:2174)
at com.ibm.msg.client.jakarta.jms.internal.JmsContextImpl.commit(JmsContextImpl.java:273)
... 3 more
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2003
at com.ibm.mq.jmqi.remote.api.RemoteFAP.handleDoomedTransaction(RemoteFAP.java:12720)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.MQCMIT(RemoteFAP.java:9812)
at com.ibm.mq.jmqi.monitoring.JmqiInterceptAdapter.MQCMIT(JmqiInterceptAdapter.java:246)
at com.ibm.msg.client.jakarta.wmq.internal.WMQSession.syncpoint(WMQSession.java:1961)
Could you please advise on the possible cause or provide guidance on resolving this issue?
Thank you.
------------------------------
madhu ram
Original Message:
Sent: Mon September 22, 2025 12:16 AM
From: Morag Hughson
Subject: Issue with Reconnect
Hi Madhu,
Many thanks for providing that extra clarification. So, there is just the one application here. You have configured reconnection options on the application and it has reconnected to the queue manager after you restarted the queue manager but it has not remade the open handles - that's what it sounds like you are saying.
When client reconnection is used, what is supposed to happen is that the client code detects that the connection was broken (MQRC_BROKEN_CONNECTION (2009)) and it retries the MQCONN until such time as it is successful and then it re-runs all the MQOPENs to recreate open handles for all the queues that the application had open before the connection was broken.
I wonder therefore whether something else might be going on here, and that it is not the reconnection settings that have caused the connection to be re-established because if it had been, the open handles would also be re-established.
You say that you restarted the queue manager in order to test your reconnecting settings. Can you show me the commands you used to both stop, and restart the queue manager. Perhaps you didn't cause an MQRC_BROKEN_CONNECTION reason code for your application, but instead an MQRC_Q_MGR_QUIESCING, and so all the handles to queues were closed.
Were there are errors shown in the log for your application related to the time when the queue manager was stopped an restarted? That might also provide some clues.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Mon September 22, 2025 12:08 AM
From: madhu ram
Subject: Issue with Reconnect
Hello Morag,
Sorry for the confusion.Please find my response below
- You say, "after restarting the QM, the connection was re-established" - and I believe you are talking about your application here - the one that you have set the reconnect settings you describe onto.---yes, i am talking about the java application here .
- Then you say "the queues are losing their readers" - what do you mean by "readers" here? You say that you "need to restart the gateway application". Is the gateway application the same application as above, or a different one? If it is a different one, does this 'gateway application' also have reconnection settings?--by readers i mean the "open input count",yes gateway application is the same as the java application.(I have set the reconnect logic on the java application.)
------------------------------
madhu ram
Original Message:
Sent: Sun September 21, 2025 11:53 PM
From: Morag Hughson
Subject: Issue with Reconnect
Hi Madhu,
Sorry to hear you are having problems. I want to ask for some clarification on your question.
You say, "after restarting the QM, the connection was re-established" - and I believe you are talking about your application here - the one that you have set the reconnect settings you describe onto.
Then you say "the queues are losing their readers" - what do you mean by "readers" here? You say that you "need to restart the gateway application". Is the gateway application the same application as above, or a different one? If it is a different one, does this 'gateway application' also have reconnection settings?
Hopefully you can provide some additional information to allow me to more fully understand your question, and therefore try to help you.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Sun September 21, 2025 11:47 PM
From: madhu ram
Subject: Issue with Reconnect
Hello all,
I have a client JMS application in Spring Boot which connects to IBM MQ.
Recently, I included the reconnect options as follows:
// IBM MQ Client Auto-Reconnect SettingsmqConnectionFactory.setClientReconnectOptions(WMQConstants.WMQ_CLIENT_RECONNECT);mqConnectionFactory.setClientReconnectTimeout(600); // 600 seconds (10 min)// IBM MQ Client Auto-Reconnect Settings
I tested this by stopping the queue manager (QM). As expected, the application got disconnected, but after restarting the QM, the connection was re-established.
However, I noticed an issue:
After reconnection, messages start to flow, but the queues are losing their readers. I need to restart the gateway application each time to restore the queue readers.
Is this normal to have an error : JMSCMQ0002: 'MQCMIT and ('MQCC_FAILED') ; reason '2003'?
If not, should an application that connects to MQ stay connected all the time until it reads a message?
Could anyone help explain why this is happening or suggest how to ensure the readers are automatically restored after reconnect?
Thanks
Madhu
------------------------------
madhu ram
------------------------------