Browse Prior Art Database

A system for time dependent debug information storage

IP.com Disclosure Number: IPCOM000241825D
Publication Date: 2015-Jun-02
Document File: 3 page(s) / 172K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to improve the efficiency of logging mechanisms for software applications. The novel method is to buffer the last x seconds of logging in memory (without writing it in the log file) until the system reaches an exception. At that time, the system writes the buffered data to the log file followed by the actual exception and the next y seconds of detailed logging after the exception.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

A system for time dependent debug information storage

Software applications generally have a logging mechanism that records in a text file different information related to application performance in order to assist in debug defects. The level of information saved in the log file can vary from CRITICAL only (i.e. the logging only writes exceptions and stack traces in the log file) to DEBUG or TRACE
(i.e. the logging writes every detail of what is happening, values for variables, etc.).

If, from a system resources perspective, the use of the CRITICAL level is fine, because there are not that many critical issues occurring in an application, the context of the error is missing. That makes the debugging difficult, and programmers often need to change the level of output to more detail, for example TRACE, in order to investigate

what the program did before and after the exception.

Unfortunately, the more detail that is requested, the more resources (in terms of central processing unit (CPU) and disk input/output (I/O)) the logging mechanism requires,

which makes the resultant file (on the hard drive) larger. For example, if it takes five minutes to reach the point of failure, the logging has exported megabytes of unnecessary information, irrelevant to the issue. Besides generating a large file which takes a lot resources (including CPU, I/O, and hard drive space), the file is difficult to read because it is hard to isolate the exception within a large amount of irrelevant information.

A preferred method is to report the detailed information only when necessary, ignoring it the rest of the time, in order to save resources and improve readability.

The novel solution is a method to buffer the last x seconds of logging in memory (without writing it in the log file) until the system reaches an exception. At that time, the system writes the buffered data to the log file followed by the actual exception and the next y seconds of detailed logging after the exception.

This approach reduces the CPU and I/O resources used, at the cost of additional fixed memory consumption. The process maintains a manageable size for the log file and helps programmers quickly and easily identify the error.

Normally, the logging level in a production environment is set up to only log exceptions, mostly because of the cost of exporting detailed information. With this method, because the cost of logging more detailed information is lower, a production environment can be set to a more detailed logging level, providing more information

when an issue occurs with limited overall performance impact.

In a system, users specify the desired logging level. Typically, the levels are DEB...