GitHub user ppkarwasz added a comment to the discussion: Does Log4j2 compress
rolled log files concurrently with writing to the new log file?
Hi @stoyanpetrov1920-spec,
Yes, the compression of the rolled log file is performed **asynchronously** and
does **not block** the creation of the new active log file. Logging continues
immediately after the rollover as long as the compression finishes **before the
next rollover** occurs.
In Log4j Core, the **synchronous** (blocking) part of a rollover is
intentionally minimized and normally includes only the operations required to
free up the current log file name (such as renaming or moving the active file)
so a new file can be opened. However, with `DirectWriteRolloverStrategy`, this
step is effectively eliminated because each rolled file is written directly
with a **unique name**. As a result, no file move or rename is needed during
rollover, and the synchronous phase is essentially empty.
> [!NOTE]
> If you are rolling **by size as well as by time**, make sure your
> `filePattern` includes `%i`, for example:
>
> ```
> filePattern="app-%d{yyyy-MM-dd}-%i.log.xz"
> ```
>
> Without `%i`, multiple size-based rollovers within the same day would try to
> use the same file name, leading to collisions or overwritten logs.
Because compression happens asynchronously, it will not add latency to your
logging calls. However, it will still consume some system resources (CPU and
disk I/O) in the background. If you are concerned about that, or if you want to
avoid large compression jobs at rollover time, you might consider appenders
that **compress data incrementally per event** rather than at rollover time,
for example, the [Y-Scope CLP
appenders](https://github.com/y-scope/log4j2-appenders).
GitHub link:
https://github.com/apache/logging-log4j2/discussions/3964#discussioncomment-14761509
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
