The last 3-4 weeks have been an interesting and painful, ‘beat your head against the wall’ type of developer nightmare.
A customer was getting some very strange behavior with Universal File Mover (UFM) setting the Correlation Id of a message when running as a Windows service.
When UFM is watching a directory for files to appear, UFM will launch a different thread, for each file found, and each thread will uploaded the ‘found file’ to MQ. At any given instances, there could be 5, 10, 20, etc. threads running and all will be uploading their particular file to MQ (on separate MQ connections).
In the log, I could see many threads setting the Correlation Id (different values per thread) at the same time (same timestamp) but the receiving side’s message would have the same Correlation Id (when it should be different).
I changed JVMs as I thought I had a JVM issue, it did not help. I checked for static variables/methods – nothing found. I synchronized the methods, etc. to make sure nothing was shared between the threads. The only thing that did not change was MQ (v7.5.0.3) and I have a feeling that somewhere in MQMessage or related class there is a static field. This issue was easy to reproduce (only on MQ v7.5.0.3), as soon as more than 4 threads (with separate MQ connections) tried to put messages, at the same time, the Correlation Id got messed up (same value for each message). No other field or data would be altered/duplicated. Very weird to say the least.
Anyway, I got fed up and figured I would switch UFM to use MQ Properties to get around the Correlation Id issue. There are lots of people using UFM to send and receive files via MQ (using many different MQ versions), it just so happens that something weird happens on MQ v7.5.0.3 with UFM v1.1.0.
I updated UFM and tested it on a couple of servers and everything looked good and so I gave the update to the customer. The customer sent me the logfile and said they were getting Reason Code of 2142 (MQRC_HEADER_ERROR). I wasted over a day trying to figure out how RC of 2142 related to setting MQ Properties. It doesn’t. It is a totally incorrect/invalid Reason Code for the error.
Through trial and error, I realized that the CLASSPATH was missing the ‘com.ibm.mq.pcf.jar’ JAR file. A PMR was opened with IBM and I am trying to get them to fix the exception but they said it is a configuration issue and there is no defect. I happily admit that I did not include the MQ PCF jar file and it was my mistake but MQ should be returning ‘java.lang.NoClassDefFoundError: com/ibm/mq/pcf/***’ (where *** is the class it was looking for). So far, IBM is sticking with there ‘user configuration error and there is no defect in MQ’.
The Windows service I use for the JVM must know about all JAR files because it builds and loads everything internally. Hence, the reason the missing MQ PCF JAR file. I have updated the Windows service and UFM is now flying and the customer is happy.
In this discussion with various people on the web, it has become apparent that IBM has made a total mess of the CMQC class and totally confuses most Java developers. There are 4 CMQC classes and 3 of the 4 of them are deprecated.
Developers should only be using ‘com.ibm.mq.constants.CMQC’ class.
- These 3 CMQC classes are deprecated:
- com.ibm.mq.headers.CMQC
- com.ibm.mq.headers.pcf.CMQC
- com.ibm.mq.pcf.CMQC
Also, IBM deprecated ‘com.ibm.mq.MQC’ class in MQ v7.0.0.0 then undeprecated it. Seriously. See the tech note: https://www-01.ibm.com/support/docview.wss?uid=swg21423244. About 2/3 of the fields in MQC class are deprecated (after the flip, flop).
Finally, some developers prefer to use the ‘com.ibm.mq.constants.MQConstants’ class rather than the
‘com.ibm.mq.constants.CMQC’ class. That is fine but please note that the MQConstants class is much, much larger than the CMQC class.
Regards,
Roger Lacroix
Capitalware Inc.
One Response to Java and MQ issues with UFM and MQ v7.5.0.3