[ http://jira.qos.ch/browse/LBCORE-131?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu resolved LBCORE-131. ------------------------------- Fix Version/s: 0.9.24 Resolution: Fixed Tom, thank you for this excellent bug report. Issue fixed in http://github.com/ceki/logback/commit/e666c7d8a37
SizeAndTimeBasedFNATP will overwrite previous logging files when File property is set at RollingFileAppender ------------------------------------------------------------------------------------------------------------
Key: LBCORE-131 URL: http://jira.qos.ch/browse/LBCORE-131 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Reporter: tomliliu Assignee: Ceki Gulcu Fix For: 0.9.24
Here's the failure case: Configuration: <appender name="appender" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>c:/var/tmp/base.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern> c:/var/tmp/%d{yyyy-MM-dd_HH}.%i.log </FileNamePattern> <TimeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <MaxFileSize>1KB</MaxFileSize> </TimeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern> %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n </Pattern> </layout> </appender> Steps to reproduce: 1. Start the application 2. base.log was created. 3. yyyy-MM-dd_HH.0.log was created on rollover 4. rebounce the application 5. log to base.log 6. yyyy-MM-dd_HH.0.log was created on rollover, overwrite the previous yyyy-MM-dd_HH.0.log. Logging messages are lost. It looks like the root cause is that SizeAndtimeBasedFNATP does not update the currentPeriodsCounter when parentsRawFileProperty is set. if (tbrp.getParentsRawFileProperty() == null) { String regex = tbrp.fileNamePattern.toRegex(dateInCurrentPeriod); String stemRegex = FileFilterUtil.afterLastSlash(regex); computeCurrentPeriodsHighestCounterValue(stemRegex); } SizeAndTimeBasedFNATP should update currentPeriodsCounter regardless whether parentsRawFileProperty is set or not. Here's a fix works for me. SizeAndTimeBasedFNATP.java @Override public void start() { // we depend on certain fields having been initialized // in super.start() super.start(); archiveRemover = new SizeAndTimeBasedArchiveRemover(tbrp.fileNamePattern, rc); archiveRemover.setContext(context);
// we need to get the correct value of currentPeriodsCounter. // usually the value is 0, unless the appender or the application // is stopped and restarted within the same period //if (tbrp.getParentsRawFileProperty() == null) { String regex = tbrp.fileNamePattern.toRegex(dateInCurrentPeriod); String stemRegex = FileFilterUtil.afterLastSlash(regex); computeCurrentPeriodsHighestCounterValue(stemRegex);
//} started = true; } void computeCurrentPeriodsHighestCounterValue(final String stemRegex) { File file = new File(getCurrentPeriodsFileNameWithoutCompressionSuffix()); File parentDir = file.getParentFile(); File[] matchingFileArray = FileFilterUtil .filesInFolderMatchingStemRegex(parentDir, stemRegex); if (matchingFileArray == null || matchingFileArray.length == 0) { return; } FileFilterUtil.reverseSortFileArrayByName(matchingFileArray); currentPeriodsCounter = FileFilterUtil.extractCounter(matchingFileArray[0], stemRegex);
//If parentsRawFileProperty is set, we should increment currentPeriodsCounter by one in order to avoid overwrite the last archive file. if(tbrp.getParentsRawFileProperty() != null) { currentPeriodsCounter ++; } } Thanks, Tom
-- 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