[
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
