GitHub user ppkarwasz added a comment to the discussion: What are the differences between the various prefixes in asynchronous loggers?
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](https://logging.apache.org/log4j/2.x/manual/architecture.html#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](https://logging.apache.org/log4j/2.x/manual/architecture.html#LoggerConfig) This separation gives Log4j Core its powerful [**reconfiguration reliability**](https://logging.apache.org/log4j/2.x/manual/architecture.html#reconfiguration): 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: ```properties 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.*`)](https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsAllAsync) ### 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.*`)](https://logging.apache.org/log4j/2.x/manual/async.html#SysPropsMixedSync-Async) > [!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.*`](https://logging.apache.org/log4j/3.x/manual/async.html#common-configuration-properties), simplifying configuration and avoiding ambiguity. GitHub link: https://github.com/apache/logging-log4j2/discussions/3817#discussioncomment-13735118 ---- This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
