[ http://jira.qos.ch/browse/LBCORE-147?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-147: ----------------------------------- 1) "The application is typically not used at the weekend - so for two days a week the application is running but there is no logging activity. I can't believe that's an especially unusual scenario." You are right. The scenario is perfectly plausible for an application deployed in the context of a business with clearly defined opening hours. You'd need a heartbeat thread logging at regular intervals to overcome this problem. 2) If the value of Q is independent of the duration of the rollover period, so is maxQ. It would be incorrect to make it dependent just because it suits us better.
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