What are the differences between the various prefixes in asynchronous loggers?

[youngledo]

I saw in the document "https://logging.staged.apache.org/log4j/2.x/manual/async.html#log4j2.asyncLoggerConfigRingBufferSize" that there are two ways of writing it, differing only in the prefix, but I didn't quite understand what the actual difference between them is.

[ppkarwasz]

That’s an excellent question — and one that gets to the heart of Log4j Core’s architecture.

To answer it properly, we need to distinguish between two key components in Log4j Core: Logger and LoggerConfig. While other logging frameworks delegate the tasks of both to a single object, Log4j treats them as distinct — and for good reason.

Logger vs LoggerConfig

• A Logger is the object your application code interacts with — it implements the org.apache.logging.log4j.Logger interface.
  See: Architecture: Logger

• A <Logger>, <Root>, <AsyncLogger>, or <AsyncRoot> element in your configuration file corresponds to a LoggerConfig — the component that actually defines how events are handled.
  See: Architecture: LoggerConfig

This separation gives Log4j Core its powerful reconfiguration reliability: during configuration reloads, a Logger may temporarily be associated with two LoggerConfig instances — the old and the new. This allows the system to continue processing log events without losing any during the switch.

Asynchronous Logging: Two Approaches

This distinction between Logger and LoggerConfig also plays a crucial role in asynchronous logging. Log4j offers two mechanisms:

Full Asynchronous Loggers (AsyncLogger)

This mode makes the Logger itself asynchronous. It hands off all log events to a background thread immediately.

• To enable set:

  log4j2.contextSelector = org.apache.logging.log4j.core.async.AsyncLoggerContextSelector

• These are not configured via XML elements — they are initialized through the context selector and tuned using:
  System Properties for Full Async Loggers (log4j2.asyncLogger.*)

Mixed Asynchronous Loggers (AsyncLoggerConfig)

Here, the LoggerConfig is asynchronous — but only partly:

1. Events are passed synchronously to the parent logger (if additivity == true)
2. Only afterward are they handed off to the async thread

• These are configured using <AsyncLogger> and <AsyncRoot> in the XML configuration
• Tuned via:
  System Properties for Mixed Async Loggers (log4j2.asyncLoggerConfig.*)

Caution

Don't Mix the Two

Using both async Logger and async LoggerConfig introduces two asynchronous handoff stages, which is inefficient and generally discouraged. Stick to one approach per application.

Looking Ahead to Log4j 3.x

In Log4j 2.x, the separation between full and mixed async loggers extended even to configuration properties, which could be confusing.

In Log4j 3.x, this has been streamlined: both types of async loggers will be tunable using unified property prefixes like
log4j.async.logger.*, simplifying configuration and avoiding ambiguity.