Introduction
JTraceDump provides a facility to keep a history of application processing
steps in memory and dump it in case of an error. It is not a replacement,
but an addition to trace- or debug-logging.
Usually, trace-logs are only active during development and testing stage
of an application. When the application goes into production, trace
logs are usually disabled for performance reasons. Now, if there is
a problem later on (for example a null-pointer-problem due to a threading
problem in a server), there is often very few information available
about what led to the problem. Typically, as the developer, you'd have
to get the administrator to enable the trace logging again and then
tell the user to reproduce the error. Then you could analyze the logs
to find the problem. However, the error might just not be reproducible
at all, and the whole process involves a lot of people (= overhead),
especially in large corporate environments.
The bottomline is: You'd better have all context information the first
time the problem occurs. But you don't want to have trace logging enabled
all the time. So what do you do?
- You write a logging wrapper for the logger you use. This is a good practice anyway, since it allows to change the logging facility later easily without having to change all source files.
- In your logging wrapper, in the method that calls the logger's "trace" logging method, you call the "trace" method of this tracedump facility, even when the logger's tracing is disabled. The JTraceDump facility keeps the logs in memory only (so there's almost no performance impact). It stores the records in a fixed array of configurable size, preventing any memory problems. Which size is optimal may depend on the application.
- Once an unexpected exception or another problem occurs, the "dump"
method of the JTraceDump class is called. It creates a text file in
the log directory with all log records and environment information
(system properties etc.). The file gets a name with a specific ID.
In the regular application error log, one single record may be written
which refers to that separate dump file for further information about
the problem.
All in all, it's similar to any old-style dump file mechanism (like
a core dump in Unix, for example). This class was developed and used
in a real-world server project, where a Java-based server which had
to use a proprietary, native library through JNI crashed occasionally.
The crashes were hard to reproduce, so a way had to be found to get
tracing information even when tracelogs were disabled.
Actually, JTraceDump is only one class, and it's no rocket-science at all. But nevertheless, I could not find anything similar anywhere else, so I had to do it by myself.