Affects Version/s: None
Fix Version/s: 2.11.2
We are working on migrate Log4J to Log4J2 in Hadoop codebase.
It seems like the SizeBasedTriggeringPolicy is not honored when using the DirectWriteRolloverStrategy if the machine restarts before it writes the size limit specified in the policy. We are coming across an issue where if a process using Log4j2 restarts continuously in a short time period, the size of the most recently created log will grow indefinitely.
The behavior we expect is for the log output to always be written to the most recently created file by the RollingFile appender, and for the log file size to never exceed what was specified in the SizeBasedTriggeringPolicy.
Our setup uses SLF4J and Log4j2 using the Log4j 1.2 API.
In reproducing the issue locally, I took an example of the usage of the DirectWriteRolloverStrategy from https://logging.apache.org/log4j/2.x/manual/appenders.html#TriggeringPolicies and modified it slightly to not compress the archived files. Here is the code used.
First I ran this such that the log generated would be somewhere around half the size limit specified.
Then I ran it again, and noted the file sizes generated:
Here, the second log which was 121M at the time the first run finished now exceeds the 250M limit specified in the SizeBasedTriggeringPolicy. If another 250M is written to the same file without a restart happening, the behavior becomes what we expect.
Internally, this could be caused by the inability to specify a fileName parameter in DirectWriteRolloverStrategy, because the file specified with fileName is used for tracking the amount written to the log so far when Log4j first starts up. Otherwise, the size written so far would become zero.The Log4j version used is 2.11.0. Here is the full list of the Maven dependencies used.