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

HC (JIRA) noreply-jira at qos.ch
Mon Jul 4 17:29:54 CEST 2011


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

HC edited comment on LBCORE-147 at 7/4/11 5:28 PM:
---------------------------------------------------

Hello,

I can see the same issue on our production machines. We use logback and logs are not deleted using ch.qos.logback.core.rolling.TimeBasedRollingPolicy with ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP triggering policy.

A subset of the original problem is the case when the log filename does not contain directory information. This particular issue can be replicated by slightly modifying one of the existing tests from logback's test suite: TimeBasedRollingWithArchiveRemovalTest.java. Please see the test named dailyChronologSizeBasedRolloverWhenLogFilenameDoesNotContainDirectory() in the attached file. 

Best Regards,

Horace

      was (Author: hc):
    Hello,

I can see the same issue on our production machines. We use logback and logs are not deleted using ch.qos.logback.core.rolling.TimeBasedRollingPolicy with ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP triggering policy.

It seems issue can be replicated by slightly modifying one of the existing tests from logback's test suite: TimeBasedRollingWithArchiveRemovalTest.java. Please see the test named dailyChronologSizeBasedRolloverWhenLogFilenameDoesNotContainDirectory() in the attached file. It seems that if the log filename does not contain directory information no files are deleted. 

At a quick glance, the faulty code would be in SizeAndTimeBasedArchiveRemover.clean() 
  1.  File parentDir = archive0.getParentFile();
  2.  File[] matchingFileArray = FileFilterUtil.filesInFolderMatchingStemRegex(parentDir, stemRegex); 

The first line returns null for the specified case and hence FileFilterUtil.filesInFolderMatchingStemRegex() will return immediately when a null parameter is sent.

Best Regards,

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

        


More information about the logback-dev mailing list