logback : SizeAndTimeBasedRollingPolicy not deleting files with 4 digit “%i”

Question

We are using SizeAndTimeBasedRollingPolicy/SizeAndTimeBasedFNATP in our product (logback 1.1.3). Here is snip from the logback configuration file :

 <appender name="SERVER_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${MY_LOGS}/myabc.log</file> <append>true</append> <!-- Roll log file on both time (per day) and size (250mb). Gzip on roll. --> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- location and name of rolled log files --> <fileNamePattern>${MY_LOGS}/myabc-%d{yyyy-MM-dd}.%i.gz</fileNamePattern> <!-- keep 30 days worth of history --> <maxHistory>30</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <!-- whenever the file size reaches 250MB, roll it --> <maxFileSize>250MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <encoder> <pattern>%d{yyyy-MM-dd'T'HH:mm:ss.SSS} [%thread] %-5level %logger{24} [%C{1}.%M]</pattern> </encoder> </appender> 

The log files generated have the following names : myabc-2016-11-21.0.gz, myabc-2016-11-21.1.gz, myabc-2016-11-21.2.gz etc.

The problem is if a log file has extension (%i) more than 3 digits, it is not being deleted after 30 days (maxHistory). For example, myabc-2016-11-21.0.gz gets deleted after 30 days, but myabc-2016-11-21. 1000 .gz is NOT getting deleted.

Is there any other appender/configuration which I need to add to the logback configuration file to make sure files with more than 3 digit extension also gets deleted or is it a bug in logback?

[I have tried with logback 1.1.7, but that did not help]

Answer 1

I have the same problem, looked to logback source code (version 1.2.3)

package - ch.qos.logback.core.rolling.helper

and found this line buf.append("(\\\\d{1,3})");

so it is hardcoded to 1-3 digit integer, where 1000 exceeds this interval and new log files with index over 1000 are not replacing the old ones, but keep appending to filesystem.

Answer 2

It is a bug in logback. Here is the jira and here is the proposed fix ( PR ).

Answer 3

This issue already fixed in 1.3.0-alpha1
you can check the commit here

https://github.com/qos-ch/logback/commit/f264607fb450

they change from

buf.append("(\\d{1,3})");

to

buf.append("(\\d+)");

and the official news here
https://logback.qos.ch/news.html

TimeBasedArchiveRemover is now able to deal with indexes over 999. This fixes LOGBACK-1175 reported by Diego Furtado who also provided the relevant PR.