You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Robert Sevcik (JIRA)" <ji...@apache.org> on 2013/01/11 17:14:12 UTC
[jira] [Commented] (LOG4NET-83) Allow flushing into file every X
milliseconds
[ 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
Re: [jira] [Commented] (LOG4NET-83) Allow flushing into file every X milliseconds
Posted by Dominik Psenner <dp...@gmail.com>.
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 <ge...@glympse.com>:
> 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) <ji...@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
>
>
--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C #
##########################################################
Re: [jira] [Commented] (LOG4NET-83) Allow flushing into file every X milliseconds
Posted by George Chung <ge...@glympse.com>.
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) <ji...@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
>