Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Sun, 31 Mar 2013 06:01:17 +0000 (UTC)
From: "Ralph Goers (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12631163.1360193033607.82151.1364709677604@arcas>
In-Reply-To: <JIRA.12631163.1360193033607@arcas>
References: <JIRA.12631163.1360193033607@arcas>
Subject: [jira] [Commented] (LOG4J2-163) Create asynchronous Logger for
 low-latency logging
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13618253#comment-13618253 ] 

Ralph Goers commented on LOG4J2-163:
------------------------------------

I started to look at the code and I have a couple of issues:
1. @author tags are discouraged by the ASF board of directors and Log4j 2 doesn't use them. The idea here is that the community owns the code. Individual contributions are recognized through the changes.xml and subversion commits.
2. I am seeing com.lmax.disruptor classes in the source code. This is very bad practice as it means a log4j jar will now be exposing classes from a third party.  The pom.xml should reference the disruptor jar as a dependency. I'd fix this but I don't know what version you based this on.
                
> 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-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