You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2013/03/02 22:51:13 UTC
[jira] [Commented] (LOG4J2-163) Create asynchronous Logger for
low-latency logging
[ https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591536#comment-13591536 ]
Remko Popma commented on LOG4J2-163:
------------------------------------
I found some other classes that don't compile with JDK5:
org.apache.logging.log4j.core.helpers.UUIDUtil
org.apache.logging.log4j.core.layout.HtmlLayout
org.apache.logging.log4j.core.layout.XmlLayout
org.apache.logging.log4j.message.ExtendedThreadInformation
org.apache.logging.log4j.message.LocalizedMessage
org.apache.logging.log4j.message.ThreadDumpMessage
What is the rationale for targeting JDK5?
I would think that people/companies conservative enough to not upgrade Java are very unlikely to switch their logger from Log4j to Log4j2 as well...
(Note that as of last month, JDK6 is now officially End of Public Updates: http://www.oracle.com/technetwork/java/eol-135779.html )
> 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
>
>
> 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