I am developing an Eclipse RCP application and have gone to some pains to get log4j2 to work within the app. All seems to work fine now, and as a finishing touch I wanted to make all loggers asynchronously.
I've managed to get the LMAX Disruptor on the classpath, and think I've solved the issue of providing sun.misc
as well. Set the VM argument -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
in the run config and set up log4j2.xml file correctly as well. I think. And that's where the problem is. I'd like to be able to verify that my application logs asynchronously in the proper fashion, so I can enjoy the benefits latency-wise.
How can I - then - verify that my loggers are working asynchronously, utilising the LMAX Dirsuptor in the process?
Asynchronous Loggers are a new addition in Log4j 2. Their aim is to return from the call to Logger. log to the application as soon as possible. You can choose between making all Loggers asynchronous or using a mixture of synchronous and asynchronous Loggers.
Mule runtime engine (Mule) 4 uses Log4j 2 asynchronous logging by default, so the logging operation happens in a separate thread from the message processing, and the latter can continue without having to wait for the log operation to complete.
Asynchronous logging reduces application pauses due to UL by decoupling logging from disk I/O.
Configuration: the root element of a log4j2 configuration file; the status attribute represents the level at which internal log4j events should be logged. Appenders: this element contains a list of appenders; in our example, an appender corresponding to the System console is defined.
There are two types of async logger, handled by different classes.
AsyncLogger
class - activated when you use AsyncLoggerContextSelector
AsyncLoggerConfig
class - when your configuration file has <AsyncRoot>
or <AsyncLogger>
elements nested in the configuration for <Loggers>
.In your case you are making all loggers async, so you want to put your breakpoint in AsyncLogger#logMessage(String, Level, Marker, Message, Throwable)
.
Another way to verify is by setting <Configuration status="trace">
at the top of your configuration file. This will output internal log4j log messages on log4j is configured. You should see something like "Starting AsyncLogger disruptor...". If you see this all loggers are async.
Put a breakpoint in org.apache.logging.log4j.core.async.AsyncLoggerConfig#callAppenders
. Then you can watch as the event is put into the disruptor. Likewise org.apache.logging.log4j.core.config.LoggerConfig#callAppenders
should be getting hit for synchronous logging OR getting hit from the other side of the disruptor for async logging (at which point everything is synchronous again).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With