logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Dorrat <simon.dor...@gsjbw.com>
Subject New feature request: Add "Flush on Level" capability to FileAppen der
Date Wed, 05 May 2004 03:25:42 GMT
I submitted a feature request to Bugzilla last week and have not heard
anything.  I guess thats because you're all pretty busy.  Has anyone had a
chance to think about it?  As I said I'm happy to do the work.

Simon
================================

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.

Simon


Goldman Sachs JBWere
Disclosure of Interest
ORG:  Goldman Sachs JBWere and/or its affiliates expect to receive or intend to seek compensation
for financial and advisory services in the next 3 months from the company, its parent, or
its wholly owned or majority owned subsidiary.



GOLDMAN SACHS JBWERE PTY LTD DISCLAIMER

Goldman Sachs JBWere Pty Ltd and its related entities distributing this document and each
of their respective directors, officers and agents ("the Goldman Sachs JBWere Group") believe
that the information contained in this document is correct and that any estimates, opinions,
conclusions or recommendations contained in this document are reasonably held or made as at
the time of compilation.  However, no warranty is made as to the accuracy or reliability of
any estimates, opinions, conclusions, recommendations (which may change without notice) or
other information contained in this document and, to the maximum extent permitted by law,
the Goldman Sachs JBWere Group disclaims all liability and responsibility for any direct or
indirect loss or damage which may be suffered by any recipient through relying on anything
contained or omitted from this document.

Goldman Sachs JBWere does not represent or warrant the attached files are free from computer
viruses or other defects.  The attached files are provided, and may only be used, on the basis
that the user assumes all responsibility for any loss, damage or consequence resulting directly
or indirectly from use.


---------------------------------------------------------------------
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