You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our application is a JAVA back end app running inside a Tomcat. In a high level it reads input from IBM MQ, process it, persists it in the ORACLE DB and writes the output to an MQ. It is a distributed two phase commit transaction world where Atomikos serves as a transaction manager. We use Spring JMS API. Currently the set up is we are in JAVA 11 and now we are trying to upgrade the app to JAVA 17.
We use org.springframework.jms.connection.CachingConnectionFactory with com.atomikos.jms.AtomikosConnectionFactoryBean as connection factory bean. For every polling of the MQ messages in JAVA 11, the below logs gets printed out from org.springframework.jms.core.JmsTemplate.class in the spring-jms jar. "Executing callback on JMS Session: Cached JMS Session: com.ibm.mq.jms.MQXAQueueSession@39f839d6"
We can see that in the first set of logs, we have the com.ibm.mq.jms.MQXAQueueConnection@6bd9b89d object getting printed but not in the upgraded app logs where we have null. This is the discrepancy we want to understand.
We are not allowed to connect directly to the test queue managers from local machine hence with a limited debugging opportunity, we found that when we upgrade the com.ibm.mq.allclient jar iteratively, things are fine until 9.2.3.0 and this cached session prints out to null starting from 9.2.4.0 which is the IBM version which was upgraded to JAVA 17. Hence I believe for this issue there is some correlation between IBM MQ jars and Atomikos after upgrading to JAVA 17. I'm exactly not sure what/which is the fault here but with the logs I'm suspecting on atomikos.
Can you please kindly have a look?
The text was updated successfully, but these errors were encountered:
Our application is a JAVA back end app running inside a Tomcat. In a high level it reads input from IBM MQ, process it, persists it in the ORACLE DB and writes the output to an MQ. It is a distributed two phase commit transaction world where Atomikos serves as a transaction manager. We use Spring JMS API. Currently the set up is we are in JAVA 11 and now we are trying to upgrade the app to JAVA 17.
We use org.springframework.jms.connection.CachingConnectionFactory with com.atomikos.jms.AtomikosConnectionFactoryBean as connection factory bean. For every polling of the MQ messages in JAVA 11, the below logs gets printed out from org.springframework.jms.core.JmsTemplate.class in the spring-jms jar. "Executing callback on JMS Session: Cached JMS Session: com.ibm.mq.jms.MQXAQueueSession@39f839d6"
Dependencies used: com.ibm.mq.allclient - 7.5.0.0, spring-jms - 5.3.x, Atomikos - 5.0.8 (free version)
Now when we upgraded to JAVA 17, the dependencies are also upgraded to the latest compatible.
Dependeicies used: com.ibm.mq.jakarta.client - 9.4.0.0, spring-jms - 6.1.5, Atomikos - 6.0.0 (free version)
But now, after this upgrade, we get the logs as, "Executing callback on JMS Session: Cached JMS Session: Cached JMS Session: null"
Enabling the log trace of Atomikos and IBM MQ jars, we get,
With com.ibm.mq.allclient - 7.5.0.0, spring-jms - 5.3.x, Atomikos - 5.0.8 (free version)
With com.ibm.mq.jakarta.client - 9.4.0.0, spring-jms - 6.1.5, Atomikos - 6.0.0 (free version)
We can see that in the first set of logs, we have the com.ibm.mq.jms.MQXAQueueConnection@6bd9b89d object getting printed but not in the upgraded app logs where we have null. This is the discrepancy we want to understand.
We are not allowed to connect directly to the test queue managers from local machine hence with a limited debugging opportunity, we found that when we upgrade the com.ibm.mq.allclient jar iteratively, things are fine until 9.2.3.0 and this cached session prints out to null starting from 9.2.4.0 which is the IBM version which was upgraded to JAVA 17. Hence I believe for this issue there is some correlation between IBM MQ jars and Atomikos after upgrading to JAVA 17. I'm exactly not sure what/which is the fault here but with the logs I'm suspecting on atomikos.
Can you please kindly have a look?
The text was updated successfully, but these errors were encountered: