You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by Michael Schall <mi...@gmail.com> on 2010/06/17 22:08:33 UTC
Rolling files on date/time boundaries doesn't support a maximum
number of backup files
This is a feature that many have asked for and a few have submitted patches
for. I downloaded the latest patch and it seems to have issues with several
new features in trunk.
https://issues.apache.org/jira/browse/LOG4NET-27
I have attached an implementation that seems to be working how I think it
should, but thought I would ask on this list to see what people thought.
The main question I have is, should the files removed because of the
"MaxDateRollBackups" property be completely date based?
All logs that follow assume you are rolling over on 2010-06-18 with a date
pattern of .yyyy-MM-dd.
Lets say i have the following logs and I set my MaxDateRollBackups to 4
foo.2010-06-17.log
foo.2010-06-16.log
foo.2010-06-15.log
foo.2010-06-15.1.log
foo.2010-06-15.2.log
foo.2010-06-14.log
foo.2010-06-13.log
foo.2010-06-12.log
foo.2010-06-11.log
Should I keep:
foo.2010-06-17.log
foo.2010-06-16.log
foo.2010-06-15.log
foo.2010-06-15.1.log
foo.2010-06-15.2.log
foo.2010-06-14.log
Or keep:
foo.2010-06-17.log
foo.2010-06-16.log
foo.2010-06-15.log
foo.2010-06-15.1.log
My current implementation keeps the former. I followed the
MaxSizeRollBackups idea of not caring about Date (It only removes the one
for the current period) so I don't care about size rolls. It also makes it
easer as I don't have to work about count direction and other properties.
If the date parsed is older than MaxSizeRollBackups RollPoint (setup by
date pattern) it is removed.
This is really how I would like to see it anyway because if I have a busy
logging day and it rolls several times by size, I don't want to lose
yesterdays logs.
The possible down side this way is if you have the following logs, with
a MaxDateRollBackups to 4. I'm fine with this, but thought I would see what
others thought.
foo.2010-06-17.log
foo.2010-06-16.log
foo.2010-06-12.log
foo.2010-06-11.log
The last two would be removed.
Thoughts?
Thanks for any feedback. This has not been tested well, but seems to work
how I have it configured. I'm also not positive it works with < .Net 2.0 I
checked docs and tried not to use anything not supported.
Mike
Re: Rolling files on date/time boundaries doesn't support a maximum
number of backup files
Posted by Michael Schall <mi...@gmail.com>.
I found a few issues with my implementation so I'm sending out the updated
file. The RollingFileAppender will now check on startup of there are files
that need to be deleted and I have fixed how I was finding the delete date.
On Thu, Jun 17, 2010 at 3:08 PM, Michael Schall <mi...@gmail.com>wrote:
> This is a feature that many have asked for and a few have submitted patches
> for. I downloaded the latest patch and it seems to have issues with several
> new features in trunk.
> https://issues.apache.org/jira/browse/LOG4NET-27
>
> I have attached an implementation that seems to be working how I think it
> should, but thought I would ask on this list to see what people thought.
>
> The main question I have is, should the files removed because of the
> "MaxDateRollBackups" property be completely date based?
>
> All logs that follow assume you are rolling over on 2010-06-18 with a date
> pattern of .yyyy-MM-dd.
>
> Lets say i have the following logs and I set my MaxDateRollBackups to 4
> foo.2010-06-17.log
> foo.2010-06-16.log
> foo.2010-06-15.log
> foo.2010-06-15.1.log
> foo.2010-06-15.2.log
> foo.2010-06-14.log
> foo.2010-06-13.log
> foo.2010-06-12.log
> foo.2010-06-11.log
>
> Should I keep:
> foo.2010-06-17.log
> foo.2010-06-16.log
> foo.2010-06-15.log
> foo.2010-06-15.1.log
> foo.2010-06-15.2.log
> foo.2010-06-14.log
>
> Or keep:
> foo.2010-06-17.log
> foo.2010-06-16.log
> foo.2010-06-15.log
> foo.2010-06-15.1.log
>
> My current implementation keeps the former. I followed the
> MaxSizeRollBackups idea of not caring about Date (It only removes the one
> for the current period) so I don't care about size rolls. It also makes it
> easer as I don't have to work about count direction and other properties.
> If the date parsed is older than MaxSizeRollBackups RollPoint (setup by
> date pattern) it is removed.
>
> This is really how I would like to see it anyway because if I have a busy
> logging day and it rolls several times by size, I don't want to lose
> yesterdays logs.
>
> The possible down side this way is if you have the following logs, with
> a MaxDateRollBackups to 4. I'm fine with this, but thought I would see what
> others thought.
>
> foo.2010-06-17.log
> foo.2010-06-16.log
> foo.2010-06-12.log
> foo.2010-06-11.log
>
> The last two would be removed.
>
> Thoughts?
> Thanks for any feedback. This has not been tested well, but seems to work
> how I have it configured. I'm also not positive it works with < .Net 2.0 I
> checked docs and tried not to use anything not supported.
>
> Mike
>