Implementation of Java Log caching mechanism

Overview

Log technology provides important support for the quality and service of the product. The JDK has added a logging mechanism after version 1.4 to facilitate Java developers. But this kind of logging mechanism is based on static log level, that is, before the program runs the need to set down the log level to be printed, this will bring some inconvenience.

In the log function provided by JDK, the log level is refined to 9 levels to distinguish the use of different logs, to record an error, to record the normal running information, or to record detailed debugging information. Because the log level is static, if the log level is set too high, the low-level log is difficult to print out, so that when the error occurs, it is difficult to track the cause of the error, is often used in the way in the error occurred, had to adjust the log level to a relatively low level, and then to trigger the error, Make the root of the problem appear. But this problem needs to change the product configuration, and then trigger the problem to debug the way the product user experience is poor, and some problems can be accidental, the environment is complex and other reasons difficult to trigger.

Conversely, if the log level is initially adjusted to a lower then there will be a lot of useless information in the middle of the log, and when the product is more complex, will result in a large log file, refreshing quickly, can not timely record effective information, or even become a performance bottleneck, thereby reducing the log function on the product's help.

This article solves this problem by caching all level logs with the help of the Memoryhandler class in the Java Logging and outputting them at the right time. It mainly revolves around the definition of memoryhandler and the processing of logging.properties documents.

Instances are attached as follows, assuming that the user needs to view the previously occurring error message containing Exception in case of a serious error in the product, as a basis for diagnosing the cause of the problem. One solution to using the Java buffering mechanism is to save the log entries that are generated during all product runs in a Exception circular buffer queue, and when a critical error (SEVERE) occurs, output the log in the buffer queue to the specified platform for user reference.

Introduction to the Java logging mechanism

Java log mechanism in many articles are introduced, in order to facilitate the understanding of the later articles, here a brief introduction to some of the keywords used in this article.

Off, Severe, Warning, Info, Config, Fine, Finer, Finest, all nine log levels are defined in LEVEL:JDK, with the definition off to the highest level of the log and all to the lowest level. Each log must correspond to one level. The level definition is used primarily to classify the severity of the log and to control whether the log is output.

LogRecord: Each log is recorded as a LogRecord, which stores information such as class name, method name, thread ID, printed message, and so on.

Logger: The basic unit of the log structure. The Logger is stored in memory in a tree structure, and the root node is root. Com.test (if present) must be the parent node of the Com.test.demo (if present), that is, the existing logger of the prefix matching must be the parent node of this logger. This definition of parent-child relationship can provide users with a more free control granularity. Because if no processing rules are defined in the child nodes, such as level handler, formatter, and so on, the processing rules in the parent node are used by default.

Handler: Used to process LogRecord, the default Handler can be connected to a chain, in turn to LogRecord processing.

Filter: Log filter. In the JDK, there is no implementation.

Formatter: It is primarily used to define a LogRecord output format.

Figure 1. Java Log processing process

Figure 1 shows a logrecord processing process. A log entry process is first Logger, which defines the level that can be passed, and if logrecord levels are higher than Logger, filter (if any) is filtered. If no level is defined, the level of the parent Logger is used. Handler in the process is similar, where Handler also defined can pass level, and then filter filtering, through if there are other Handler, directly to the back of the Handler processing, otherwise it will be directly bound to the formatter above the output to the point Fixed position.

Before implementing the log cache, the Filter and Formatter two auxiliary classes are described first.

Filter

Filter is an interface, mainly to filter logrecord, control whether the LogRecord for further processing, it can be bound under Logger or Handler.

As long as you can control the LogRecord by adding the filter logic to the Boolean isloggable (LogRecord) method, if you want to record only those log records that have Exception, then you can do so through the manifest, and of course you need to first The filter is bound to the corresponding Logger or Handler by calling the SetFilter (filter) method or the configuration file.

Listing 1. Implementation of a Filter instance

@Override Public
Boolean isloggable (LogRecord record) { 
if (Record.getthrown ()!=null) {return 
       true; 
} else{return 
        false;  
}