I could have sworn that there was a configuration option for RollingFileAppender that rolled the file based on either a fill criteria or a time elapsed criteria or both. Am I mistaken?
On Fri, Jan 11, 2013 at 8:14 AM, Robert Sevcik (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/LOG4NET-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551218#comment-13551218] > > Robert Sevcik commented on LOG4NET-83: > -------------------------------------- > > Hi, I was thinking to submit a feature request / RFC, but this thread is > pretty much it. > > My idea was to inherit from ForwardingAppender to create a > PulsingAppender. PulsingAppender would be able to send pulse logging events > to the connected appenders with a configured time interval. > > A pulse would be a special kind of LoggingEvent - perhaps an inherit from > LoggingEvent implementing new IPulseLoggingEvent interface or just > containing some specific labeling data. > > Pulse aware appenders would be able to treat pulse events specially, for > instance carry out actions of up keep. They could silence the pulse or not > based on configuration perhaps. > > Pulse unaware appenders would simply log the pulse logging event. > > My motivation is the following scenario. A component writes an error log > very rarely, perhaps only on start-up. The error log appender does not > receive any event for months. There comes the day we need to clean the logs > up and we find the ages old error log still locked. We do not want to > restart the apps just to release a log. A tempting short-cut answer might > be to pulse-log from the application, but then you'd have to see the scale > of our systems and how hard it is to push a change through the development > cycle. > > Please let me know your thoughts. I'm willing to make a prototype. There > are concerns about the thread pool exhaustion, please elaborate. > > My prototype would make RollingFileAppender roll over, TextWriterAppender > flush, ForwardingAppenders able to stop the Pulse on Pulse. There would be > configuration available regarding whether to action on Pulse and whether to > silence the Pulse. Care would need to be taken around filtering the pulse > out or not, most likely with a new IFilter implementation > > Kind regards, Rob > > > > Allow flushing into file every X milliseconds > > --------------------------------------------- > > > > Key: LOG4NET-83 > > URL: https://issues.apache.org/jira/browse/LOG4NET-83 > > Project: Log4net > > Issue Type: New Feature > > Components: Appenders > > Affects Versions: 1.2.10 > > Environment: All > > Reporter: Tal G > > Priority: Minor > > Fix For: 1.2 Maintenance Release > > > > > > In FileAppender you can specify either immediate flush on every message > or not flushing at all. > > Immediate flushing reduces performance in 10% - 20%, but when flushing > is skipped, then it is likely that the last few log events will not be > recorded on disk when the application exits. > > I suggest adding a parameter that flushes to file every X millisecond. > In this case you will gain most of the 10%-20% performance, and you will > minimize the lost of logs when the application exits. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira >
