[ http://jira.qos.ch/browse/LBCORE-147?page=com.atlassian.jira.plugin.system.i... ] 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