[
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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
