Not surprisingly, when I tested:
- Subscribing to a topic with JMS
- Subscribing to a topic with Java (non-JMS)
They both showed that the internal JMQI routine was starting with a MQGet buffer size of 4KB and auto-adjusting the size of the buffer as needed (all behind the scenes). Hence, when I used MQ Auditor, I can see an excessive number of MQGets returning reason code of 2080 (MQRC_TRUNCATED_MSG_FAILED). For each MQGet that fails with a reason code of 2080, the internal JMQI routine will increase the buffer size and re-issue the MQGet. This is bad from a performance point of view.
If you don’t know what I talking about, please go read the following to blog posting:
- Tuning JMS Programs for Optimum MQ Get API Calls Performance
- Tuning Java Programs for Optimum MQ Get API Calls Performance
- How to Improve Your Java/JMS MQ Tuning Cred.
The bottom-line is that if you set the JVM environment variable ‘com.ibm.mq.jmqi.defaultMaxMsgSize’ to a reasonable size you can:
- reduce the number of failed MQGet API calls
- which in turn will make your applications faster
- that lowers the CPU consumption of client server
- and lowers the CPU consumption of MQ server.
Update: Currently, the JVM environment variable ‘com.ibm.mq.jmqi.defaultMaxMsgSize’ is undocumented. Hence, the usage may change in a future release.
Regards,
Roger Lacroix
Capitalware Inc.
