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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
