[ 
https://issues.apache.org/jira/browse/LOG4J2-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-164.
------------------------------


Confirmed. Thanks for your prompt response!
                
> 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

Reply via email to