Tracing IBM MQ classes for JMS applications
The trace facility in IBM® MQ classes for JMS is provided to help IBM Support to diagnose customer issues. Various properties control the behavior of this facility.
Before you begin
- For Long Term Support, the trace control utility is removed from the product at IBM MQ 9.4.0.
- For Continuous Delivery, the trace control utility is removed from the product at IBM MQ 9.3.3. IBM MQ 9.3.2 is the last Continuous Delivery release that it is delivered with.
- If dynamic trace is needed to diagnose an issue, IBM Support can guide you through the steps to gather trace as required.
About this task
- If the issue is easy to recreate, then collect an IBM MQ classes for JMS trace by using a Java System Property. For more information, see Collecting an IBM MQ classes for JMS trace by using a Java system property.
- If an application needs to run for a period of time before the issue occurs, collect an IBM MQ classes for JMS trace by using the IBM MQ classes for JMS configuration file. For more information, see Collecting an IBM MQ classes for JMS trace by using the IBM MQ classes for JMS configuration file.
If you are unsure which option to use, contact your IBM Support representative and they will be able to advise you on the best way to collect trace for the issue that you are seeing.
If a severe or unrecoverable error occurs, First Failure Support Technology (FFST) information is recorded in a file with a
name of the format JMSCC xxxx.FDC where
xxxx
is a four-digit number. This number is incremented to
differentiate .FDC files.
- Trace is active, and
traceOutputName
is set - The FFDC directory is created as a subdirectory of the directory to which the trace file is being written.
- Trace is not active or
traceOutputName
is not set - The FFDC directory is created as a subdirectory of the current working directory.
For more information about FFST in IBM MQ classes for JMS, see FFST: IBM MQ classes for JMS.
The JSE common services uses java.util.logging as its trace and logging
infrastructure. The root object of this infrastructure is the LogManager. The log
manager has a reset method that closes all handlers and sets the log level to
null
, which in effect turns off all the trace. If your application or application
server calls java.util.logging.LogManager.getLogManager().reset(), it closes all
trace, which might prevent you from diagnosing any problems. To avoid closing all trace, create a
LogManager class with an overridden reset() method that does
nothing, as in shown the following example:
package com.ibm.javaut.tests;
import java.util.logging.LogManager;
public class JmsLogManager extends LogManager {
// final shutdown hook to ensure that the trace is finally shutdown
// and that the lock file is cleaned-up
public class ShutdownHook extends Thread{
public void run(){
doReset();
}
}
public JmsLogManager(){
// add shutdown hook to ensure final cleanup
Runtime.getRuntime().addShutdownHook(new ShutdownHook());
}
public void reset() throws SecurityException {
// does nothing
}
public void doReset(){
super.reset();
}
}
java -Djava.util.logging.manager=com. mycompany.logging.LogManager ...