RE: New feature request: Add "Flush on Level" capability to FileA ppender

[Paul Smith <Pa...@lawlex.com.au>]

Yup, and there is already a CylicBuffer & CyclicBufferList classes available
in log4j to use for this (this is what the SMTPAppender uses).

> -----Original Message-----
> From: Simon Dorrat [mailto:simon.dorrat@gsjbw.com]
> Sent: Friday, May 07, 2004 9:27 AM
> To: 'Log4J Developers List'
> Subject: RE: New feature request: Add "Flush on Level" capability to
> FileA ppender
> 
> 
> Thats an interesting requirement.  I have never considered 
> that before, but
> could imagine a few people wanting that.  It could be an easy 
> or difficult
> addition depending on which design pattern was used.  (See 
> the bugzilla
> history for the discussion of possible patterns between me 
> and Paul).  So if
> others think its worthwhile that could influence the design choice.
> 
> Simon
> 
> > -----Original Message-----
> > From:	Alan Brown [SMTP:abrown@opstechnology.com]
> > Sent:	Thursday, 6 May 2004 4:52 AM
> > To:	Log4J Developers List
> > Subject:	RE: New feature request: Add "Flush on Level" 
> capability to
> > FileAppender
> > 
> > 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.
> > 
> > alan
> > 
> > -----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
> > FileAppender
> > 
> > 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
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> 
> 
> 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
> 

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