[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    [jira] [Updated] (LOG4J2-163) Create asynchronous Logger for low-latency logging
From:       "Remko Popma (JIRA)" <jira () apache ! org>
Date:       2013-03-31 10:41:16
Message-ID: JIRA.12631163.1360193033607.82350.1364726476094 () arcas
[Download RAW message or body]


     [ 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-20130331a.patch

Ralph, thanks for your feedback!
Please find attached file LOG4J2-163-log4j-async-20130331a.patch

This fixes the issues you mentioned:
* removed @author tags from source code
* removed com.lmax classes, declared dependency in pom, fixed imports and updated \
documentation

The disruptor version I used is 3.0.0.beta3.

(the images referenced in the manual have not changed, so I did not upload them \
again. Please unzip them into the src/site/resources/images/ directory)  
> 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: async-perf-comparison.png, 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-20130331a.patch, \
> LOG4J2-163-log4j-async-20130331-images.zip, LOG4J2-163-log4j-async-20130331.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


[prev in list] [next in list] [prev in thread] [next in thread]