[ https://issues.apache.org/jira/browse/LOG4J2-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618623#comment-13618623 ]
Remko Popma commented on LOG4J2-164: ------------------------------------ Apologies. Looks like my patch for LOG4J2-163 missed the change to AbstractOutputStreamAppender: org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender current (line 116-117): if (this.immediateFlush) { manager.flush(); proposed change: if (this.immediateFlush || event.isEndOfBatch()) { manager.flush(); > 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 > Assignee: Ralph Goers > Fix For: 2.0-beta5 > > 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: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org