logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 28647] New: - Add "Flush on Level" capability to FileAppender
Date Wed, 28 Apr 2004 03:20:15 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=28647>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=28647

Add "Flush on Level" capability to FileAppender

           Summary: Add "Flush on Level" capability to FileAppender
           Product: Log4j
           Version: 1.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Appender
        AssignedTo: log4j-dev@jakarta.apache.org
        ReportedBy: sdorrat@jbwere.com.au


New Feature Requested:
I have used logging extensively for many years and tend to have my programs 
log alot of information.  When writing to a file this can cause a performance 
impact due to very frequent disk I/O.  So my own logging libraries I used (in 
C, VB, PL/SQL) always had the ability to configure the level that the log text 
was flushed to disk.  

I have now extended FileAppender to create this feature.  It simply allows you 
to set the level that flushing occurs.  Whenever a log event is logged for 
that level or higher, a flush occurs.  i.e. if the FlushLevel is INFO, then 
when an INFO, WARN, ERROR or FATAL event is logged the stream will be flushed 
to disk. DEBUG messages will accumulate and not flush until the next INFO 
event is logged.

Justification:  
-The performance improvement allows for more detailed logging levels to be 
left permanently on, or to have less impact when they are on. 
- The logging style in most programs (certainly all mine) finish each major 
processing step logging an event at a level higher than (or at least equal to) 
the previously logged events.  Eg an operation "createOrder" may have a number 
of INFO and DEBUG msgs (and soon TRACE!) but would finish on a INFO msg 
like "Successfully created order for 1000 ORCL...".  This pattern guarantees 
that flush of all log event has occurred when the operation finishes, rather 
than waiting for some arbitrary point like a 8K buffer being filled.
-The one downside is that if a program crashes, then any final logged events 
below the threshold that occurred after the last threhold level will not 
appear in the file.  This is normally a small price to pay, as you just then 
lower the flush level and rerun so you get all events flushed.  (This assumes 
the error is repeatable, but with no flushing feature, the lower level events 
wouldnt have been turned on due to the performance hit so you are no worse off 
even if it is not).
NOTE: I have implemented a shutdown hook to address the last issue - i.e. 
automatically flush on VM exit, but that is a Java 1.3 method so cannot be 
used in Log4j as I understand it.

Current Status:
I have written a new appender "LevelFlushedFileAppender" that extends 
FileAppender that does this job.  This works fine and I am happy to submit 
it.  However I think that it would be better to alter the FileAppender itself 
and add the code directly to this, so it could be inherited in all classes 
extending FileAppender.  I am happy to implement it like this also.

Let me know if the feature is accepted or you want further information, and 
what I should do going forward.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message