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

Alexander Lauper (JIRA) noreply-jira at qos.ch
Fri Aug 26 13:49:16 CEST 2011


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

Alexander Lauper commented on LBCORE-147:
-----------------------------------------

Thank you Ceki for looking into this matter.

This comment got longer than I wanted, sorry for that ...

The assumption that at least one LoggingEvent is generated per rollover period does not hold for my app as well. As a matter of fact if the device is running flawlessly there could be quiescent periods of multiple days if not even months. Hence I am thinking of scheduling a job which logs free memory and disk space once a rollover period to avoid having gaps in log files ...

I am not too happy with the maxQ-solution. This would work in most of the cases, yes. But I'd rather prefer a solution which always works (well, who doesn't ...).

Three things which crossed my mind:

1) How is the problem solved in other logging frameworks? I guess we aren't the only ones thinking about this ...

2) How about scanning all files recursively and cleanup on appender start only and keep the existing deletion mechanism? Then you define that it's the application developpers responsibility to log at least once a rollover period. This would work when the device/machine/app is not running for an undefined duration. Quiescent periods longer than the rollover period wouldn't exist anymore when following the constraint mentioned. If one is not happy with having unneeded log entries the policy class could provide a method to trigger a rollover (if the conditions for a rollover are met) but not adding a log entry (maybe that exists already?).

3) Another approach would be something already mentioned by Dieter Mueller (logback needs to keep track of created log files). However I'd prefer if the history wasn't stored in a seperate file, but rather be kept in memory an generated on appender start.

Kind regards,
Alex

> 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