[logback-dev] [JIRA] Commented: (LBCORE-147) RollingPolicy MaxHistory not deleting old files

[Bruce E. Irving (JIRA)]

    [ http://jira.qos.ch/browse/LBCORE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12151#action_12151 ] 

Bruce E. Irving commented on LBCORE-147:
----------------------------------------

I have downloaded Logback version 0.9.30 which is supposed to fix this issue; but I have a usage scenario for which this is still broken.
The application is a desktop utility which users may run several times during the day or it may go unused for long periods.
I wanted to collect the logs for a given day in a date stamped file and to save a few days and automatically delete older files. 
For the datestamp requirement, the FileAppender would work, but to delete older files the RollingFileAppender seemed appropriate.
I am not compressing old files, so that is not an issue. I am not providing the FileAppender.file property, so each days logging goes directly into the file with today's date, and there is no need for file renaming.

As far as I can tell, the 'rolling' logic that would delete the old files is never run. The application is almost never running at midnight, so it would have run at startup and does not.  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();
  }


> RollingPolicy MaxHistory not deleting old files
> -----------------------------------------------
>
>                 Key: LBCORE-147
>                 URL: http://jira.qos.ch/browse/LBCORE-147
>             Project: logback-core
>          Issue Type: Bug
>          Components: Rolling
>    Affects Versions: 0.9.18
>         Environment: linux 2.6.18 64bits apache-tomcat-6.0.20 java/jre1.6.0_18
>            Reporter: Rafael Diaz Maurin
>            Assignee: Ceki Gulcu
>             Fix For: 0.9.30
>
>         Attachments: TimeBasedRollingWithArchiveRemovalTest.java
>
>
> The MaxHistory does not do the trick : the old files are not deleted at all :
> cat logging.xml
>  <appender name="IDP_ACCESS" class="ch.qos.logback.core.rolling.RollingFileAppender">
>         <File>/shibboleth-idp/logs/idp-access.log</File>
>             <Append>false</Append>
> 	<ImmediateFlush>true</ImmediateFlush>
>        <RollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
>             <FileNamePattern>/shibboleth-idp/logs/old/idp-access-%d{yyyy-MM-dd_HH-mm}.log.gz</FileNamePattern>
> 	    <MaxHistory>3</MaxHistory>
>         </RollingPolicy>
>         <layout class="ch.qos.logback.classic.PatternLayout">
>             <Pattern>%msg%n</Pattern>
>         </layout>
>     </appender>

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