[
https://issues.apache.org/jira/browse/LOG4J2-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573290#comment-13573290
]
Ralph Goers commented on LOG4J2-163:
------------------------------------
I believe the call to checkConfiguration used to be in LoggerConfig but I had
to move it to the Logger to avoid some problems, but I don't recall what they
were now.
By definition, if a synchronous logger is called from a child thread it is no
longer synchronous and may not behave in the way the application expects. In a
sense, delegation really isn't delegation. If LoggerConfig a.b.c is
asynchronous it can be scheduled and then its parent can immediately be
processed in the same thread that scheduled a.b.c. This has the desirable
effect that if an exception is thrown and suppressExceptions is set to false
then the application will receive the exception. This behavior is impossible to
accomodate if the synchronous LoggerConfig is invoked from an asynchronous one.
In other words - what you are expressing would result in a configuration that
behaves like:
<asynchLogger name="a.b.c" level="debug">
<appender-ref ref="appender1"/>
<logger name="a.b" level="debug">
<appender-ref ref="appender2"/>
</logger>
</asynchLogger>
even though what they actually configured was:
<asynchLogger name="a.b.c" level="debug">
<appender-ref ref="appender1"/>
<asynchLogger>
<logger name="a.b" level="debug">
<appender-ref ref="appender2"/>
</logger>
> 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
