I have not got the pros of "pulse events". One could already treat some events specially, keyword: filter. Please come up with better usecases. :-)
2013/1/11 George Chung <[email protected]>: > 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) <[email protected]> > 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 > > -- Dominik Psenner ## OpenPGP Key Signature ################################# # Key ID: B469318C # # Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C # ##########################################################
