logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Sevcik (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4NET-83) Allow flushing into file every X milliseconds
Date Fri, 11 Jan 2013 16:32:13 GMT

    [ https://issues.apache.org/jira/browse/LOG4NET-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551218#comment-13551218
] 

Robert Sevcik edited comment on LOG4NET-83 at 1/11/13 4:31 PM:
---------------------------------------------------------------

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 (LOG4NET-16), 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

                
      was (Author: robajz):
    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

Mime
View raw message