logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominik Psenner" <dpsen...@gmail.com>
Subject RE: New RollingFileAppender semantics
Date Tue, 20 Sep 2011 14:24:23 GMT
>>Maybe something like "Date", "Size", "ApplicationUptime", "RPCTrigger",
>.. ?

Yea. I just came up with this idea. If you for example have a remoting
appender that finally writes with a rolling file appender, other
applications could trigger a file roll with an RPC call. The specific
implementation could set a Boolean flag that causes the condition to match
on the next iteration and subsequently roll the file. But this is just a
fancy idea of how versatile this API could become. :-)

>What you are really saying is that the new code needs to have enough
>extension points that others could easily add new roll conditions.  My
>concern is in how to provide that functionality and get renaming and
>deleting right.

Since it's still our responsibility to rename files and the API just
provides only a "condition" and a "new file name" (or maybe even a set of
new filenames?) the code that renames (i.e. rolls) the file is still in the
base implementation.

>+1 or even +2 on the time stamp condition.
>I like the time stamp condition idea, but does that mean at hour 24 or
>24 hours from starting time?  I think it means hour 24, so what symbol
>could we add to make it relative to starting time.  Maybe a + so that
>"+24" means 24 hours from when I started.  Would a relative to start
>time take away your requirement for a ApplicationUptime roll condition?

So many pluses, I'm overwhelmed of the positive feedback! :-) I would stick
with the crond semantics here. They support these 5 cases:

1) * matches every number
2) 5 matches exactly 5
3) */5 matches everything with *%5 == 0, i.e. 0,5,10,15,20,25,..
4) 5,7 matches for 5 or 7
5) 5-7 matches 5,6 or 7

See here: http://adminschoice.com/crontab-quick-reference

This is simple and even more powerful than the old syntax. The configuration
would require some more syntactic sugar to identify the rolling strategies.
I.e. something like:

  <rollFileCondition month="*" day="*" hour="24" minute="*"
type="log4net.Appender.RollingFileAppenderNG.CronCondition" />
  <rollFileNamingStrategy value="Date" />

Or maybe:

  <CronRollFileCondition month="*" day="*" hour="24" minute="*" />
  <rollFileNamingStrategy value="Date" />

Yet we would have to design a format that works for 3rd party
implementations too.

>Questions about rollFileNamingStrategy.
>Date makes sense, I assume that we would include the datePattern
>somewhere as <rollFileNameByDatePattern = "yyMMdd"/>  etc.
>How do we incorporate that with a size rollover to achieve names similar
>to what are produced now (or should be produced now) as
>It seems to me that we would need to pair a naming strategy with each
>roll strategy and indicate where that part of the name goes into the
>final file name.
>This brings me to File= parameter that has {Date} and {Size} etc. to
>indicate where date and size patterns are to be inserted.  (Likewise for
>any other rolling condition.) If this idea is acceptable, then we do not
>have to worry about the date pattern separator or preserve extension
>etc. because it is all handled by the file pattern.  The biggest
>downside that I see at this time is scanning the File= parameter to
>determine what goes where to create the directory search, but it should
>be doable without too much unfixable code.

This will become tricky. Rolling by date and a unpredictable part in the
filename (like date) forces a algorithm candidate to search a set of files
and therefore the algorithm automatically degrades to something in between
O(n) and O(n^3). Rotating often a large amount of backups can devastate the
performance. So maybe we'll have to distinguish two rolling strategies and
never mix them:

1) either by date, which is simply a copy of the file and the existing file
becomes truncated
2) or by incremental number, which allows an upper bound of files, but still
does copy the current file and truncates it afterwards

>>Is much clearer than the old-fashioned thing:


View raw message