I recently updated my log4j 1.2.13 to log4j 2.17.2 using log4j 1.2 bridge API.
My existing RollingFileAppender configuration is as below:
log4j.appender.app=org.apache.log4j.RollingFileAppender log4j.appender.app.layout=org.apache.log4j.PatternLayout log4j.appender.app.layout.ConversionPattern=%d %-5p [%-4t] %c{1}.%M(%L) | %m%n log4j.appender.app.File=${applicationLogs}/app.log log4j.appender.app.Encoding=UTF-8 log4j.appender.app.MaxFileSize=10KB log4j.appender.app.MaxBackupIndex=5 As per Apache log4j documentation: if logging to a file named file.log, when the file size reaches the specified size limit, the contents are archived in a file named file.log.1 and file.log is truncated. When the size limit is reached the second time, file.log.1 is renamed to file.log.2; contents from file.log are archived to file.log.1 and file.log is truncated.
But after the library update, the contents are getting archived in serial manner: when the size limit is reached the second time, file.log.1 is not getting renamed to file.log.2; instead contents from file.log are archived to file.log.2 and file.log is truncated.
1 Answer
This is clearly a bug in log4j-1.2-api (I reported it as apache/logging-log4j2#1650).
You can work around this problem by switching to the Log4j 2.x configuration format (cf. documentation) and set fileIndex="min" on the DefaultRolloverStrategy.
The 2.x equivalent of your 1.x configuration will then look like:
<RollingFile name="app" fileName="${sys:applicationLogs}/app.log" filePattern="${sys:applicationLogs}/app.log.%i"> <PatternLayout charset="UTF-8" pattern="%d %-5p [%-4t] %c{1}.%M(%L) | %m%n"/> <SizeBasedTriggeringPolicy size="10KB"/> <DefaultRolloverStrategy fileIndex="min" max="5"/> </RollingFile> 
