logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: rolling in log4j2
Date Sun, 02 Feb 2014 08:11:02 GMT
Yes, I was thinking along similar lines.

Something like https://issues.apache.org/jira/browse/LOG4J2-491
but perhaps more general.

I haven't got it all worked out yet but I find the current
DefaultRolloverStrategy difficult to unit-test. E.g., file deletes are not
actions, but renaming and zipping are actions.
It would be nice to separate the logic that generates the "action plan"
from the execution of that action plan. That would facilitate unit testing
and perhaps make it easier to let users insert their own actions in the
chain. Determining deletion candidate files could be part of the logic that
generates the action plan.
Sorry if this all sounds a bit vague atm. Need to think about this some
more...


On Sunday, February 2, 2014, Gary Gregory <garydgregory@gmail.com> wrote:

> Perhaps a different approach would be to have a separate clean up object
> that you give a pattern and an age. This would let you separate the
> rollover concern from the clean up.
>
> Gary
>
>
> On Sat, Feb 1, 2014 at 11:02 PM, Remko Popma <remko.popma@gmail.com>
> wrote:
>
> > I see. Basically, you are trying to avoid deleting files that were not
> the
> > result of a rollover, is that correct?
> > I don't have a good answer to that yet.
> >
> > Another use case is patterns like this:
> > filePattern="logs/%d{yyyy-MM}/app-%d{yyyy-MM-dd}.%i.log"
> > where the directory name is or contains a date pattern. So just using the
> > fixed text prefix part of the filePattern is not sufficient to achieve
> your
> > goal...
> >
> > Alternatively,
> > filePattern="logs/%d{yyyy-MM}/webapp42/app-%d{yyyy-MM-dd}.%i.log"
> > where the directory with the date pattern is not the parent directory of
> > the rolled over log files.
> >
> > So I thought we should limit the scan to the directory containing the
> > rolled over log files...
> >
> > Obviously, if the parent directory is a pattern that changes every month,
> > having a "maxAge=2M" (2 months) would never result in a match if we only
> > scan the directory holding the rolled over log files, so older log files
> > would never get deleted. That should not be a problem though.
> >
> > Hm... The only way I can think of to avoid deleting files that were not
> the
> > result of rollover is by pattern matching on the name...
> > I was hoping to avoid that by simply defining the functionality as "any
> > file in that directory is a candidate for deletion", but I guess this may
> > be surprising for users...
> >
> >
> >
> >
> > On Sun, Feb 2, 2014 at 12:13 PM, Kireet <kireet@feedly.com> wrote:
> >
> > > That wouldn't be ideal for me as I have several different log files
> being
> > > produced in the same directory, but I do see how it would get pretty
> > > complicated to pattern match old files to delete selectively. I could
> > > separate things by folder I guess. What about at least filtering the
> > files
> > > by everything up until the first pattern? E.g. for the below
> > > "app-%d{yyyy-MM-dd}.%i.log", what about only deleting files that start
> > with
> > > app- and are older than the maxAge?
> > >
> > >
> > > On 2/1/14 6:59 PM, Remko Popma wrote:
> > >
> > >> Agreed that this seems a common use case. Looking at the
> > >> LOG4J2-435<https://issues.apache.org/jira/browse/LOG4J2-435> ticket,
> > >>
> > >> you're now the third person asking for this feature...
> > >>
> > >> Team, what about adding a maxAge attribute to DefaultRolloverStrategy?
> > The
> > >> attribute would accept values like "3d" (delete older than 3 days),
> > >> similarly "4w" (4 weeks), "5M" (5 months) etc.
> > >> The scanned directory would be the parent dir of the rolled over file
> > >> specified by the {{filePattern}} attribute, and any file in that
> > directory
> > >> would be candidates for deletion.
> > >>
> > >> Thoughts?
> > >>
> > >>
> > >> On Sunday, February 2, 2014, Arkin Yetis <arkinyetis@gmail.com>
> wrote:
> > >>
> > >>  I had opened the following for this:
> > >>> https://issues.apache.org/jira/browse/LOG4J2-435
> > >>> Perhaps you can see if this would meet your need and vote for/watch
> it,
> > >>> if
> > >>> it does.
> > >>>
> > >>>
> > >>> On Sat, Feb 1, 2014 at 11:39 AM, Kireet <kireet@feedly.com
> > <javascript:;>>
> > >>>
> > >>> wrote:
> > >>>
> > >>>  Thanks for the update. So I would need to use an external process
to
> > >>>>
> > >>> clean
> > >>>
> > >>>> up older files? This seems like a pretty common use case though
> right?
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 2/1/14 12:19 AM, Remko Popma wrote:
> > >>>>
> --
> E-Mail: garydgregory@gmail.com <javascript:;> | ggregory@apache.org<javascript:;>
> Java Persistence with Hibernate, Second Edition<
> http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message