[logback-dev] [JIRA] (LOGBACK-1386) Incorrect rolling files by TimeBasedArchiveRemover if totalSizeCap limit is exceeded

[QOS.CH (JIRA)]

Aleksei Lebedev created LOGBACK-1386:
----------------------------------------

             Summary: Incorrect rolling files by TimeBasedArchiveRemover if totalSizeCap limit is exceeded
                 Key: LOGBACK-1386
                 URL: https://jira.qos.ch/browse/LOGBACK-1386
             Project: logback
          Issue Type: Bug
          Components: logback-core
    Affects Versions: 1.3.0-alpha4, 1.1.8
         Environment: Mac OS X, JDK8/9
            Reporter: Aleksei Lebedev
            Assignee: Logback dev list
            Priority: Critical


TimeBasedArchiveRemover doesn't get into account the oldest history files when rollover happens and totalSizeCap limit is exceeded.

In the worst case this leads to an increase in the total log file size up to 2 times above totalCapSize.

It can be reproduced with following configuration:
{code:xml}
<configuration scan="true" scanPeriod="10 seconds" debug="true">
    <appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>mylog.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>mylog-%d{yyyyMMdd-HHmm}.%i.log</fileNamePattern>
            <maxFileSize>2KB</maxFileSize>
            <maxHistory>1</maxHistory>
            <totalSizeCap>10KB</totalSizeCap>
            <cleanHistoryOnStart>true</cleanHistoryOnStart>
        </rollingPolicy>
        <encoder>
            <pattern>%msg%n</pattern>
        </encoder>
    </appender>
    <root level="DEBUG">
        <appender-ref ref="ROLLING"/>
    </root>
</configuration>{code}
and simple application:
{code:java}
public class Main {
    private static final Logger log = LoggerFactory.getLogger(Main.class);
    private static final long ONE_MILLION = 1_000_000L;

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 10000; i++) {
            log.info("I write in log {} times", ONE_MILLION + i);
            Thread.sleep(100L);
        }
    }
}
{code}
Example of execution result of such configuration:
{noformat}
2.0K Mar 21:44 mylog-20180304-2144.3.log <- this one should be removed
2.0K Mar 21:44 mylog-20180304-2144.4.log
2.0K Mar 21:44 mylog-20180304-2144.5.log
2.0K Mar 21:44 mylog-20180304-2144.6.log
2.0K Mar 21:44 mylog-20180304-2144.7.log
2.1K Mar 21:45 mylog-20180304-2145.0.log <- but this will be removed instead
2.0K Mar 21:45 mylog-20180304-2145.1.log
2.0K Mar 21:45 mylog-20180304-2145.2.log
2.0K Mar 21:45 mylog-20180304-2145.3.log
2.0K Mar 21:45 mylog.log
{noformat}
and in a moment:
{noformat}
2.0K Mar 21:44 mylog-20180304-2144.3.log
2.0K Mar 21:44 mylog-20180304-2144.4.log
2.0K Mar 21:44 mylog-20180304-2144.5.log
2.0K Mar 21:44 mylog-20180304-2144.6.log
2.0K Mar 21:44 mylog-20180304-2144.7.log
2.0K Mar 21:45 mylog-20180304-2145.1.log
2.0K Mar 21:45 mylog-20180304-2145.2.log
2.0K Mar 21:45 mylog-20180304-2145.3.log
2.0K Mar 21:45 mylog-20180304-2145.4.log
174B Mar 21:45 mylog.log
{noformat}



--
This message was sent by Atlassian JIRA
(v7.3.1#73012)