[
https://issues.apache.org/jira/browse/LOG4J2-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559467#comment-13559467
]
Ralph Goers commented on LOG4J2-151:
------------------------------------
I haven't had a chance to look at the attachment yet, but I'm pretty sure that
you aren't really measuring the time to log the events but rather the time
before control is returned back to the application. Simply delegating the
logging to another thread isn't likely to improve the throughput of logging.
Buffering or Immediate flush is unlikely to have any measurable effect with an
asynchronous logger since the I/O is not on the thread being measured, which is
consistent with the results above.
It would be interesting to include the AsynchAppender in the results above.
> Please facilitate subclassing Logger and LoggerContext (in
> org.apache.logging.log4j.core)
> -----------------------------------------------------------------------------------------
>
> Key: LOG4J2-151
> URL: https://issues.apache.org/jira/browse/LOG4J2-151
> Project: Log4j 2
> Issue Type: New Feature
> Components: Core
> Affects Versions: 2.0-beta3
> Reporter: Remko Popma
> Attachments: FastLog4j.zip
>
>
> I would like to create a custom logger, while reusing the
> org.apache.logging.log4j.core.Logger functionality.
> The following two changes would make subclassing possible:
> * change visibility of method Logger$PrivateConfig#logEvent(LogEvent) (line
> 265) from protected to public
> * change visibility of method LoggerContext#newInstance(LoggerContext,
> String) (line 310) from private to protected
> My use case is that I want to create an asynchronous Logger for low latency
> logging.
> This custom logger hands off control to a separate thread as early as
> possible. In my case, AsynchAppender is not a good match for my 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
