Tracing IBM MQ classes for Java applications

If you are asked to provide trace output to investigate an issue, use one of the options mentioned below:

• If the issue is easy to recreate, then collect an IBM MQ classes for Java trace by using a Java System Property. For more information, see Collecting an IBM MQ classes for Java 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 Java trace by using the IBM MQ classes for Java configuration file. For more information, see Collecting an IBM MQ classes for Java trace by using the IBM MQ classes for Java configuration file.

  From IBM MQ 10.0.0, you can direct trace data directly to stdout (standard output stream) or stderr (standard error stream) by setting the com.ibm.msg.client.commonservices.trace.outputName property to the appropriate value. If you are running applications in short-lived containers, this allows you to capture trace information through container logging mechanisms, which persist beyond the container's lifetime. For more information, see Java Standard Environment Trace stanza for Java trace.

• The IBM MQ classes for Java trace mechanism can be configured to turn trace on dynamically when it finds a specific file on the file system and stop tracing when that file no longer exists. This can be very useful if IBM Support need to see a trace from an application once an issue has occurred, or if trace needs to be collected from a critical application that cannot be stopped. For more information, see Collecting an IBM MQ classes for Java trace dynamically.

.FDC files are always written to a subdirectory called FFDC. The subdirectory is in one of two locations, depending on whether trace is active:

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.

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, which 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 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 ...