logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LOG4J2-163) Create asynchronous Logger for low-latency logging
Date Wed, 20 Mar 2013 07:25:15 GMT

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

Remko Popma updated LOG4J2-163:

    Attachment: LOG4J2-163-log4j-async-20130320.patch

Please find attached file LOG4J2-163-log4j-async-20130320.patch. 

* Updated for changes in trunk
* Upgraded to latest version of LMAX Disruptor (3.0.0-beta3) for better performance in multi-threaded
* Added manual page (src/site/xdoc/manual/async.xml)
* Added performance and JUnit tests
* Various small improvements

As before the patch file contains the new module log4j-async, and also contains patches for
the following JIRA tickets that the log4j-async module depends on: 

I also updated pom.xml to add the module and change the compilation version to Java 6.
> Create asynchronous Logger for low-latency logging
> --------------------------------------------------
>                 Key: LOG4J2-163
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-163
>             Project: Log4j 2
>          Issue Type: Improvement
>    Affects Versions: 2.0-beta4
>            Reporter: Remko Popma
>         Attachments: FastLog4j-v2-for-beta4.zip, FastLog4j-v3-for-beta4.zip, FastLog4j-v4-for-beta4.zip,
LOG4J2-163-log4j-async-20130320.patch, LOG4J2-163-log4j-async.patch
> One of the main considerations for selecting a logging library is performance, specifically,
how long it takes for a call to Logger.log to return. (See the comments of LOG4J-151 for a
discussion of latency versus application throughput and logging throughput.)
> I believe it is possible to improve this performance by an order of magnitude by having
an asynchronous Logger implementation that hands off the work to a separate thread as early
as possible. The disk I/O would be done in this separate thread. 
> AsynchAppender is not a good match for these requirements, as with that approach (a)
the logging call still needs to flow down the hierarchy to the appender, doing synchronization
and creating objects at various points on the way, and (b) when serializing the LogEvent,
the getSource() method is always called, which is expensive.

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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message