Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When not to use AsyncAppender in logback by default

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?

like image 598
Tapan Chandra Avatar asked Nov 18 '17 23:11

Tapan Chandra


People also ask

When to use AsyncAppender?

The AsyncAppender should only be considered when you have a proven issue where writing to an appender materially affects your application responsiveness/throughput.

What are Appenders in Logback?

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.

How does Logback XML work?

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.

What is Logback?

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.


1 Answers

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:

  • You can increase the buffer capacity
  • You can instruct Logback to drop events once the buffer reaches maximum capacity
  • You can control what types of events are discarded; drop TRACE events before ERROR events etc

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.

like image 53
glytching Avatar answered Oct 12 '22 23:10

glytching