[ http://jira.qos.ch/browse/LBCORE-221?page=com.atlassian.jira.plugin.system.i... ] tafit commented on LBCORE-221: ------------------------------ When using SizeAndTimeBasedFNATP triggering policy and starting the application with more than 100 log files, logback incorrectly computes the highest counter value, which causes the problem with gzipping tmp files. The tmp files are left behind and are never gzipped. The gzipping starts after the internal counter reaches the number of files with which the application was started (eg. if the application started with existing 121 log files, the gzipping process will compress the first file after 22 failures, ie. after leaving 22 tmp files uncompressed). The gzipping process is also recovered when the date changes. The logback writes Warnings about existing files to stdout, when debug="true" is set in configuration file. The issue is easily reproducible - just create more than 100 log files with the filenames matching the pattern, start the application with logback and write to log enough entries so that it will roll. Example configuration: <appender name="EXAMPLE_APPENDER" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>example.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>example.log.%d.%i.gz</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>1MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <encoder> <pattern>%date %level - %msg%n</pattern> </encoder> </appender> The call: File[] matchingFileArray = FileFilterUtil .filesInFolderMatchingStemRegex(parentDir, stemRegex); at lines 58-59 of SizeAndTimeBasedFNATP.java return only files with "%i" replaced by at most 2 digits, so the biggest number is 99. After that at line 65 currentPeriodsCounter = FileFilterUtil.findHighestCounter(matchingFileArray, stemRegex); the method findHighestCounter cannot return the number bigger than 99. "%i" can be replaced by the number with at most 2 digits, because of the regex in FileNamePattern.java. The piece of the pattern "\\d{1,2}" is used in construction of the stemRegex at two places: lines 168 and 187. https://github.com/ceki/logback/blob/master/logback-core/src/main/java/ch/qo... Changing the regex from "\\d{1,2}" to "\\d{1,9}" fixes the issue.

Error in FileNamePattern::toRegex for index (Integer) -----------------------------------------------------

Key: LBCORE-221 URL: http://jira.qos.ch/browse/LBCORE-221 Project: logback-core Issue Type: Bug Components: Pattern, Rolling Affects Versions: 0.9.29 Reporter: Dieter Mueller Assignee: Logback dev list Priority: Minor

Deletion of old archived logs on rolling failes for index > 99. We have a process which logs much, which results in more than 99 log files per day (config below), e.g. snowball_POLL_MSG_SRV_xdebug-old-2011-09-13.110.log.zip. On rolling event, only the first 99 were deleted, due to bug in FileNamePattern::toRegex for index (Integer): regEx: \d{1,2) which means digits with max length of 2. We need at least 3 digits: regEx: \d{1,3) better 4? ;-) Workarounds like increasing file size, or hourly-rollover to hold index lower than 100 are not very wellcomed. Thanks in advance, Dieter Mueller. config: <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- rollover daily --> <fileNamePattern>${log.vm.file.prefix}_xdebug-old-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern> <maxHistory>1</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>20MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy>

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira