I'm trying to manage my logging in a way in which my oldest archived logfiles are deleted once they've either reached the total cumulative size limit or reached their maximum history limit. When using the SizeAndTimeBasedRollingPolicy
in Logback 1.1.7, the rolling file appender will keep creating new archives in spite of exceeding the totalSizeCap
set.
Here's my logback.xml file for reference:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="file"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${USERPROFILE}/testlogs/test.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>
${USERPROFILE}/testlogs/%d{yyyy-MM-dd_HH}/test%i.log.zip
</fileNamePattern>
<maxHistory>7</maxHistory>
<maxFileSize>50KB</maxFileSize>
<totalSizeCap>200KB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %5p - %m%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="file" />
</root>
</configuration>
Is this a bug in logback or am I not configuring the rolling file appender correctly?
Well even the question is answered, I wanted to post the work around that we made until the bug is fixed in 1.1.8.
The bug 1166 simply does not apply totalSizeCap to the first two time units, depends on the smallest unit on the fileNamePattern you are using which means for your scenario it will not consider the logs of the first two hours for totalSize capping.
My configuration was somehow like so-taken from logback site examples-;
So we simply switched from {yyyy-MM-dd} to {yyyy-MM-dd_HH} and of course maximized the maxHistory to 30*24. Thus we made the last two hours not to be capped instead of last two days and for our case it was omittable. Of course, the log files will start to rollover in every hour but as I said it was ok for our unique case.
It's bug in Logback 1.1.7. See: http://jira.qos.ch/browse/LOGBACK-1166
I have checked,
totalSizeCap
works in Logback 1.1.8-SNAPSHOT.