[logback-dev] [JIRA] Resolved: (LBCORE-226) TimeBasedRollingPolicy does not trigger at application startup - MaxHistory not working

[Ceki Gulcu (JIRA)]

     [ http://jira.qos.ch/browse/LBCORE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ceki Gulcu resolved LBCORE-226.
-------------------------------

    Resolution: Fixed

Fixed by [1, 2]. TimeBasedRollingPolicy now admits a new boolean property called cleanHistoryOnStart. If cleanHistoryOnStart is set true, archival removal is performed at appender start up, which handles the case of short-lived applications described in this issue.

[1] https://github.com/ceki/logback/commit/be9513c
[2] https://github.com/ceki/logback/commit/14125a6

> TimeBasedRollingPolicy does not trigger at application startup - MaxHistory not working
> ---------------------------------------------------------------------------------------
>
>                 Key: LBCORE-226
>                 URL: http://jira.qos.ch/browse/LBCORE-226
>             Project: logback-core
>          Issue Type: Bug
>          Components: Rolling
>    Affects Versions: 0.9.30
>         Environment: Windows XP, Java 1.6.0_27
>            Reporter: Bruce E. Irving
>            Assignee: Ceki Gulcu
>
> I am using the RollingFileAppender with TimeBasedRolliingPolicy. The application is a desktop utility that may be run several times per day but is almost never running at midnight when the roll would normally occur.
> The log file naming is working correctly - each day's file is date stamped, but the MaxHistory is not working at all since it is not enforced at app startup.
> Pertinent config section:
>   <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
>     <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>       <fileNamePattern>MyApp_%d.log</fileNamePattern>    <!-- Daily rollover -->
>       <maxHistory>7</maxHistory>     <!-- keep 1 week history -->
>     </rollingPolicy>
>     <encoder>
>       <pattern>%date %-5level [%thread] %logger{10} %msg%n</pattern>
>     </encoder>
>   </appender>
> I found what I believe is the source of the issue in TimeBasedFileNamingAndTriggeringPolicyBase:
>   public void start() {
>     ...
>     setDateInCurrentPeriod(new Date(getCurrentTime()));
>     if (tbrp.getParentsRawFileProperty() != null) {
>       File currentFile = new File(tbrp.getParentsRawFileProperty());
>       if (currentFile.exists() && currentFile.canRead()) {
>         setDateInCurrentPeriod(new Date(currentFile.lastModified()));
>       }
>     }
>     addInfo("Setting initial period to " + dateInCurrentPeriod);
>     computeNextCheck();
>   }
> Since there is no parentsRawFileProperty, this uses the current time and sets the next check at midnight tonight. Therefore the check is not run at startup, and in my case is never run. This would work fine if dateInCurrentPeriod was set to anything before today. I would suggest the following change:
>   public void start() {
>     ...
>     File currentFile = new File(tbrp.getActiveFileName()); // Use same logic if ParentsRawFileProperty is set or not.
>     if (currentFile.exists() && currentFile.canRead()) {
>       setDateInCurrentPeriod(new Date(currentFile.lastModified()));
>     } else {
>       setDateInCurrentPeriod(0); // No current file found, force a triggering event
>       // or if the above is too brute-force: setDateInCurrentPeriod(rc.getRelativeDate(new Date(), -1));
>     }
>     addInfo("Setting initial period to " + dateInCurrentPeriod);
>     computeNextCheck();
>   }
> Note - this was originally reported as a comment on LBCORE-147; moved here to be tracked as a separate issue.
> Thanks,
> -Bruce

-- 
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