Tracing IBM WebSphere MQ classes for JMS applications
The trace facility in IBM® WebSphere® MQ classes for JMS is provided to help IBM Support to diagnose customer issues. Various properties control the behavior of this facility.
- If the issue is easy to recreate, then collect an IBM WebSphere MQ classes for JMS trace by using a Java System Property. For more information, see Collecting an IBM WebSphere 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 WebSphere MQ classes for JMS trace by using the IBM WebSphere MQ classes for JMS configuration file. For more information, see Collecting an IBM WebSphere MQ classes for JMS trace by using the IBM WebSphere 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 WebSphere MQ classes for JMS, see FFST in IBM WebSphere 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 shown in 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();
}
}
The
shutdown hook is necessary to ensure that trace is properly shut down when the JVM finishes. To use
the modified log manager instead of the default one, add a system property to the JVM startup:java -Djava.util.logging.manager=com.mycompany.logging.LogManager ...