[
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573279#comment-13573279
]
Remko Popma commented on LOG4J2-163:
------------------------------------
About the "slight loss" of performance: if it is just a couple of additional
method calls, I doubt there will be any impact.
I am more concerned about the current Logger.log implementation:
configurationMonitor.checkConfiguration() call may access the file system (1 or
2 calls to file.lastModified(), potentially reloading the config file) so I
would like to ensure that this happens in the I/O thread.
About parent delegation, I'm trying to understand what you mean. I think there
are 4 additivity=true delegation scenarios:
1. sync child -> async parent
2. async child -> sync parent
3. sync child -> sync parent
4. async child-> async parent
In 1 and 3, the call to log(LogEvent) would be in the application thread.
In 2 and 4, the call to log(LogEvent) would be in the I/O thread.
What is it you are trying to achieve?
If the child is the sync audit logger, and the parent is the async debug
logger, you want the call to auditChild.callAppenders to be synchronously (in
the application thread) and the call to debugParent.callAppenders to be
asynchronously (in the I/O thread)?
> 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
>
>
> 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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
