|
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 it a bug in logback? 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?
I have upgraded from 1.1.3 to 1.1.7. But that didn't help.
[I posted this to user mailing list, but didn't get any reply. Because of this, issue large amount log files are not getting cleaned up at our customer's production causing disk scaling issue. Considering the urgency, I am posting it as a bug.]
|