[
https://issues.apache.org/jira/browse/LOG4J2-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-164:
-------------------------------
Attachment: LOG4J2-164-patch.txt
LOG4J2-164-files.zip
Attached LOG4J2-164-files.zip and LOG4J2-164-patch.txt are based on trunk as of
Feb 11 (beta4).
Affected files:
org/apache/logging/log4j/core/LogEvent
org/apache/logging/log4j/core/impl/Log4jLogEvent
org/apache/logging/log4j/core/appender/AsynchAppender
org/apache/logging/log4j/core/appender/AbstractOutputStreamAppender
org/apache/logging/log4j/core/lookup/DateLookupTest
> Add methods is/setEndOfBatch to LogEvent (buffered appender performance
> improvement)
> ------------------------------------------------------------------------------------
>
> Key: LOG4J2-164
> URL: https://issues.apache.org/jira/browse/LOG4J2-164
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-beta4
> Reporter: Remko Popma
> Attachments: LOG4J2-164-files.zip, LOG4J2-164-patch.txt
>
>
> Many buffered Appenders have an attribute "immediateFlush" that gives users
> the option to follow each write with a flush to ensure that all messages are
> available on disk. The drawback of the immediateFlush idiom is the
> performance impact of touching the disk on every single event.
> If the appender could determine from the current LogEvent whether any more
> events are expected, it could avoid unnecessary flushes and only write to
> disk when the last event was received (or the buffer is full).
> This would work especially nicely when receiving bursts of events - a common
> scenario - when you want to avoid adding more overhead to a system that is
> already very busy.
> Asynchronous loggers and appenders are well-positioned to use such a
> mechanism: they can easily call LogEvent.setEndOfBatch(true) if the current
> event is the last one in the queue.
> The patches I proposed for LOG4J2-151 and LOG4J2-163 already use this
> mechanism internally. The FastFileAppender included in these patches checks
> if a log event is a specific class, casts the event to that class, and
> finally calls the isEndOfBatch method on that event. However I think the idea
> is generally applicable to any buffered appender and adding these methods to
> the LogEvent interface would benefit users of the existing AsynchAppender and
> OutputStreamAppender classes.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
