logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy Chastain" <...@roychastain.org>
Subject RE: New RollingFileAppender semantics
Date Tue, 20 Sep 2011 15:06:23 GMT

>>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
>only a "condition" and a "new file name" (or maybe even a set of new
>the code that renames (i.e. rolls) the file is still in the base
Yes, but the renaming strategy becomes confused here.  We have to know
how that new roll condition is renamed.

>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
I will take a look at this.

>>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
>the algorithm automatically degrades to something in between
>O(n) and O(n^3). Rotating often a large amount of backups can devastate
>performance. So maybe we'll have to distinguish two rolling strategies
and never
>mix them:
I have already written code that could parse the old datepattern and
determine where ? needed to go to do the file directory search.  That
code or a close relative can survive into the new model so, the
directory search is still just a single pass with a mask.  I even fixed
that mask to take into account the size roll increment number also,
which is why I wanted to make fixed width.

I really think we need to provide for multiple name parts as proposed
above.  I think I should be able to keep the performance acceptable.

View raw message