logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Brown" <abr...@opstechnology.com>
Subject RE: New feature request: Add "Flush on Level" capability to FileAppender
Date Wed, 05 May 2004 18:52:19 GMT
It sounds like a nice feature to me.  As an RFE to the RFE, I'd like to
see an option to cap the amount of data in the buffer.  My use case
being that when I come across an ERROR or WARN statement, I'm only
interested in the logging messages that led up to it.  

A circular buffer to hold the cached logs would prevent me worrying
about memory being sucked up by my logging system (a relevant concern if
many appenders are being used.


-----Original Message-----
From: Simon Dorrat [mailto:simon.dorrat@gsjbw.com] 
Sent: Tuesday, May 04, 2004 8:26 PM
To: 'Log4J Developers List'
Subject: New feature request: Add "Flush on Level" capability to

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
chance to think about it?  As I said I'm happy to do the work.



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
log alot of information.  When writing to a file this can cause a
impact due to very frequent disk I/O.  So my own logging libraries I
C, VB, PL/SQL) always had the ability to configure the level that the
was flushed to disk.  

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

-The performance improvement allows for more detailed logging levels to
left permanently on, or to have less impact when they are on. 
- The logging style in most programs (certainly all mine) finish each
processing step logging an event at a level higher than (or at least
the previously logged events.  Eg an operation "createOrder" may have a
of INFO and DEBUG msgs (and soon TRACE!) but would finish on a INFO msg 
like "Successfully created order for 1000 ORCL...".  This pattern

that flush of all log event has occurred when the operation finishes,

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

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

lower the flush level and rerun so you get all events flushed.  (This
the error is repeatable, but with no flushing feature, the lower level
wouldnt have been turned on due to the performance hit so you are no
even if it is not).
NOTE: I have implemented a shutdown hook to address the last issue -
automatically flush on VM exit, but that is a Java 1.3 method so cannot
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
it.  However I think that it would be better to alter the FileAppender
and add the code directly to this, so it could be inherited in all
extending FileAppender.  I am happy to implement it like this also.

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


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

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

View raw message