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.