Logback supports using an async appender with the class
ch.qos.Logback.classic.AsyncAppender
and according to the documentation, this will reduce the logging overhead on the application. So, why not just make it the default out of the box. What usecases are better served by using a sync appender. One problem I can see with the Async appender is that the log messages will not be chronological. Are there any other such limitations?
The AsyncAppender should only be considered when you have a proven issue where writing to an appender materially affects your application responsiveness/throughput.
Appenders place log messages in their final destinations. A Logger can have more than one Appender. We generally think of Appenders as being attached to text files, but Logback is much more potent than that. Layout prepares messages for outputting.
xml or logback. xml are not present, logback will default to invoking BasicConfigurator which will set up a minimal configuration. This minimal configuration consists of a ConsoleAppender attached to the root logger. The output is formatted using a PatternLayoutEncoder set to the pattern %d{HH:mm:ss.
Logback is a logging framework for Java applications, created as a successor to the popular log4j project. In fact, both of these frameworks were created by the same developer.
The AsyncAppender
acts as a dispatcher to another appender. It buffers log events and dispatches them to, say, a FileAppender
or a ConsoleAppender
etc.
Why use the AsyncAppender
?
The AsyncAppender
buffers log events, allowing your application code to move on rather than wait for the logging subsystem to complete a write. This can improve your application's responsiveness in cases where the underlying appender is slow to respond e.g. a database or a file system that may be prone to contention.
Why not make it the default behavior?
The AsyncAppender
cannot write to a file or console or a database or a socket etc. Instead, it just delegates log events to an appender which can do that. Without the underlying appender, the AsyncAppender is, effectively, a no-op.
The buffer of log events sits on your application's heap; this is a potential resource leak. If the buffer builds more quickly than it can be drained then the buffer will consume resources that your application might want to use.
The AsyncAppender
's need for configuration to balance the competing demands of no-loss and resource leakage and to handle on-shutdown draining of its buffer means that it is more complicated to manage and to reason about than simply using synchronous writes. So, on the basis of preferring simplicity over complexity, it makes sense for Logback's default write strategy to be synchronous.
The AsyncAppender
exposes configuration levers that you can use to address the potential resource leakage. For example:
The AsyncAppender
also exposes configuration levers which you can use to limit (though not eliminate) the loss of events during application shutdown.
However, it remains true that the simplest safest way of ensuring that log events are successfully written is to write them synchronously. The AsyncAppender
should only be considered when you have a proven issue where writing to an appender materially affects your application responsiveness/throughput.
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