You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Kireet <ki...@feedly.com> on 2014/02/01 01:28:36 UTC
rolling in log4j2
I am trying to use the rolling file appender in log4j2, basically I want
to roll at midnight daily and keep 3 old log files. New files are
created properly, but log4j doesn't seem to be cleaning up the old
files. Does log4j only support cleanup of files within the time period?
Here is the relevant portion of the config. I tried things with and
without the %i pattern.
<RollingFile name="Event" fileName="app.log"
filePattern="app-%d{yyyy-MM-dd}.%i.log">
<PatternLayout>
<Pattern>%m%n</Pattern>
</PatternLayout>
<Policies>
<TimeBasedTriggeringPolicy interval="1" modulate="true"/>
</Policies>
<DefaultRolloverStrategy compressionLevel="0" max="3"/>
</RollingFile>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: rolling in log4j2
Posted by Remko Popma <re...@gmail.com>.
On Monday, February 3, 2014, Gary Gregory <ga...@gmail.com> wrote:
> On Sun, Feb 2, 2014 at 3:11 AM, Remko Popma <remko.popma@gmail.com<javascript:;>>
> wrote:
>
> > 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...
> >
>
> In this area, I'd like to rename
>
> org.apache.logging.log4j.core.appender.rolling.helper
>
> to
>
> org.apache.logging.log4j.core.appender.rolling.action
>
> Thoughts?
I see what you mean: it currently only contains action classes. However, I
may need to create other support classes for what I have in mind, and that
may be a good place to put them.
Also the current name is consistent with the core.helpers package.
Would you mind if we leave it as it is for now?
-Remko
>
> Gary
>
>
> >
> > On Sunday, February 2, 2014, Gary Gregory <ga...@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 <re...@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 <ki...@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?
> > > > >>
> > > > >>
> > > > >> > E-Mail: garydgregory@gmail.com <javascript:;> <javascript:;> |
> ggregory@apache.org <javascript:;>
> > <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
> > >
> >
>
>
>
> --
> 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
>
Re: rolling in log4j2
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Feb 2, 2014 at 3:11 AM, Remko Popma <re...@gmail.com> wrote:
> 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...
>
In this area, I'd like to rename
org.apache.logging.log4j.core.appender.rolling.helper
to
org.apache.logging.log4j.core.appender.rolling.action
Thoughts?
Gary
>
> On Sunday, February 2, 2014, Gary Gregory <ga...@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 <re...@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 <ki...@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 <ar...@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
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: rolling in log4j2
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Feb 2, 2014 at 7:49 PM, Ralph Goers <rg...@apache.org> wrote:
> The actions originated with the Log4j1 extended design and code. I started
> from that and then tried to merge the rollover strategies into something
> that made sense to me. That doesn't mean it can't be changed.
>
It feels like a neat focused package. I would not like a generic 'helper'
package to become a dumping ground or kitchen sink for other stuff.
I think I'll change in the AM.
Gary
> Sent from my iPad
>
> > On Feb 2, 2014, at 12:11 AM, Remko Popma <re...@gmail.com> wrote:
> >
> > 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 <ga...@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 <re...@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 <ki...@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 <ar...@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
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: rolling in log4j2
Posted by Ralph Goers <rg...@apache.org>.
The actions originated with the Log4j1 extended design and code. I started from that and then tried to merge the rollover strategies into something that made sense to me. That doesn't mean it can't be changed.
Sent from my iPad
> On Feb 2, 2014, at 12:11 AM, Remko Popma <re...@gmail.com> wrote:
>
> 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 <ga...@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 <re...@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 <ki...@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 <ar...@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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: rolling in log4j2
Posted by Remko Popma <re...@gmail.com>.
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 <ga...@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 <re...@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 <ki...@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 <ar...@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
>
Re: rolling in log4j2
Posted by Gary Gregory <ga...@gmail.com>.
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 <re...@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 <ki...@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 <ar...@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:
> >>>>
> >>>> Kireet, you can find more details on the Jira ticket but to
> summarize,
> >>>>> you need to configure a SizeBasedTriggeringPolicy for the %i pattern
> to
> >>>>>
> >>>> be
> >>>
> >>>> useful.
> >>>>> If you do so, only "max" files are kept _within the same time
> period_.
> >>>>>
> >>>>>
> >>>>> On Sat, Feb 1, 2014 at 1:24 PM, Remko Popma <remko.popma@gmail.com<
> >>>>> javascript:;>
> >>>>>
> >>>>
> >>>> wrote:
> >>>>>
> >>>>> Kireet,
> >>>>>
> >>>>>>
> >>>>>> I can reproduce this and I've raised
> >>>>>> https://issues.apache.org/jira/browse/LOG4J2-524 to track the
> issue.
> >>>>>> I'll add comments to that Jira ticket as I make progress.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Remko
> >>>>>>
> >>>>>>
> >>>>>> On Sat, Feb 1, 2014 at 9:28 AM, Kireet <kireet@feedly.com
> <javascript:
> >>>>>> ;>>
> >>>>>>
> >>>>> wrote:
> >>>
> >>>>
> >>>>>> I am trying to use the rolling file appender in log4j2, basically
> I
> >>>>>>
> >>>>> want
> >>>
> >>>> to roll at midnight daily and keep 3 old log files. New files are
> >>>>>>> created
> >>>>>>> properly, but log4j doesn't seem to be cleaning up the old files.
> >>>>>>> Does
> >>>>>>> log4j only support cleanup of files within the time period? Here is
> >>>>>>>
> >>>>>> the
> >>>
> >>>> relevant portion of the config. I tried things with and without the %i
> >>>>>>> pattern.
> >>>>>>>
> >>>>>>> <RollingFile name="Event" fileName="app.log"
> >>>>>>> filePattern="app-%d{yyyy-MM-dd}.%i.log">
> >>>>>>> <PatternLayout>
> >>>>>>> <Pattern>%m%n</Pattern>
> >>>>>>> </PatternLayout>
> >>>>>>> <Policies>
> >>>>>>> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
> >>>>>>> </Policies>
> >>>>>>> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
> >>>>>>> </RollingFile>
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> >>>>>>> ---------
> >>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>>> <javascript:;>
> >>>>>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> >>>>>>> <javascript:;>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> <javascript:;>
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>> <javascript:;>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: rolling in log4j2
Posted by Remko Popma <re...@gmail.com>.
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 <ki...@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 <ar...@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:
>>>>
>>>> Kireet, you can find more details on the Jira ticket but to summarize,
>>>>> you need to configure a SizeBasedTriggeringPolicy for the %i pattern to
>>>>>
>>>> be
>>>
>>>> useful.
>>>>> If you do so, only "max" files are kept _within the same time period_.
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 1:24 PM, Remko Popma <remko.popma@gmail.com<
>>>>> javascript:;>
>>>>>
>>>>
>>>> wrote:
>>>>>
>>>>> Kireet,
>>>>>
>>>>>>
>>>>>> I can reproduce this and I've raised
>>>>>> https://issues.apache.org/jira/browse/LOG4J2-524 to track the issue.
>>>>>> I'll add comments to that Jira ticket as I make progress.
>>>>>>
>>>>>> Best regards,
>>>>>> Remko
>>>>>>
>>>>>>
>>>>>> On Sat, Feb 1, 2014 at 9:28 AM, Kireet <kireet@feedly.com<javascript:
>>>>>> ;>>
>>>>>>
>>>>> wrote:
>>>
>>>>
>>>>>> I am trying to use the rolling file appender in log4j2, basically I
>>>>>>
>>>>> want
>>>
>>>> to roll at midnight daily and keep 3 old log files. New files are
>>>>>>> created
>>>>>>> properly, but log4j doesn't seem to be cleaning up the old files.
>>>>>>> Does
>>>>>>> log4j only support cleanup of files within the time period? Here is
>>>>>>>
>>>>>> the
>>>
>>>> relevant portion of the config. I tried things with and without the %i
>>>>>>> pattern.
>>>>>>>
>>>>>>> <RollingFile name="Event" fileName="app.log"
>>>>>>> filePattern="app-%d{yyyy-MM-dd}.%i.log">
>>>>>>> <PatternLayout>
>>>>>>> <Pattern>%m%n</Pattern>
>>>>>>> </PatternLayout>
>>>>>>> <Policies>
>>>>>>> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
>>>>>>> </Policies>
>>>>>>> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
>>>>>>> </RollingFile>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>>> <javascript:;>
>>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>> <javascript:;>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> <javascript:;>
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>> <javascript:;>
>>>>
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: rolling in log4j2
Posted by Kireet <ki...@feedly.com>.
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 <ar...@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:
>>>
>>>> Kireet, you can find more details on the Jira ticket but to summarize,
>>>> you need to configure a SizeBasedTriggeringPolicy for the %i pattern to
>> be
>>>> useful.
>>>> If you do so, only "max" files are kept _within the same time period_.
>>>>
>>>>
>>>> On Sat, Feb 1, 2014 at 1:24 PM, Remko Popma <remko.popma@gmail.com<javascript:;>
>>>
>>>> wrote:
>>>>
>>>> Kireet,
>>>>>
>>>>> I can reproduce this and I've raised
>>>>> https://issues.apache.org/jira/browse/LOG4J2-524 to track the issue.
>>>>> I'll add comments to that Jira ticket as I make progress.
>>>>>
>>>>> Best regards,
>>>>> Remko
>>>>>
>>>>>
>>>>> On Sat, Feb 1, 2014 at 9:28 AM, Kireet <kireet@feedly.com<javascript:;>>
>> wrote:
>>>>>
>>>>> I am trying to use the rolling file appender in log4j2, basically I
>> want
>>>>>> to roll at midnight daily and keep 3 old log files. New files are
>>>>>> created
>>>>>> properly, but log4j doesn't seem to be cleaning up the old files. Does
>>>>>> log4j only support cleanup of files within the time period? Here is
>> the
>>>>>> relevant portion of the config. I tried things with and without the %i
>>>>>> pattern.
>>>>>>
>>>>>> <RollingFile name="Event" fileName="app.log"
>>>>>> filePattern="app-%d{yyyy-MM-dd}.%i.log">
>>>>>> <PatternLayout>
>>>>>> <Pattern>%m%n</Pattern>
>>>>>> </PatternLayout>
>>>>>> <Policies>
>>>>>> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
>>>>>> </Policies>
>>>>>> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
>>>>>> </RollingFile>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org<javascript:;>
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org<javascript:;>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org<javascript:;>
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org<javascript:;>
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: rolling in log4j2
Posted by Remko Popma <re...@gmail.com>.
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 <ar...@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:
> >
> >> Kireet, you can find more details on the Jira ticket but to summarize,
> >> you need to configure a SizeBasedTriggeringPolicy for the %i pattern to
> be
> >> useful.
> >> If you do so, only "max" files are kept _within the same time period_.
> >>
> >>
> >> On Sat, Feb 1, 2014 at 1:24 PM, Remko Popma <remko.popma@gmail.com<javascript:;>
> >
> >> wrote:
> >>
> >> Kireet,
> >>>
> >>> I can reproduce this and I've raised
> >>> https://issues.apache.org/jira/browse/LOG4J2-524 to track the issue.
> >>> I'll add comments to that Jira ticket as I make progress.
> >>>
> >>> Best regards,
> >>> Remko
> >>>
> >>>
> >>> On Sat, Feb 1, 2014 at 9:28 AM, Kireet <kireet@feedly.com<javascript:;>>
> wrote:
> >>>
> >>> I am trying to use the rolling file appender in log4j2, basically I
> want
> >>>> to roll at midnight daily and keep 3 old log files. New files are
> >>>> created
> >>>> properly, but log4j doesn't seem to be cleaning up the old files. Does
> >>>> log4j only support cleanup of files within the time period? Here is
> the
> >>>> relevant portion of the config. I tried things with and without the %i
> >>>> pattern.
> >>>>
> >>>> <RollingFile name="Event" fileName="app.log"
> >>>> filePattern="app-%d{yyyy-MM-dd}.%i.log">
> >>>> <PatternLayout>
> >>>> <Pattern>%m%n</Pattern>
> >>>> </PatternLayout>
> >>>> <Policies>
> >>>> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
> >>>> </Policies>
> >>>> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
> >>>> </RollingFile>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org<javascript:;>
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org<javascript:;>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org<javascript:;>
> > For additional commands, e-mail: log4j-user-help@logging.apache.org<javascript:;>
> >
> >
>
Re: rolling in log4j2
Posted by Arkin Yetis <ar...@gmail.com>.
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 <ki...@feedly.com> 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:
>
>> Kireet, you can find more details on the Jira ticket but to summarize,
>> you need to configure a SizeBasedTriggeringPolicy for the %i pattern to be
>> useful.
>> If you do so, only "max" files are kept _within the same time period_.
>>
>>
>> On Sat, Feb 1, 2014 at 1:24 PM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>> Kireet,
>>>
>>> I can reproduce this and I've raised
>>> https://issues.apache.org/jira/browse/LOG4J2-524 to track the issue.
>>> I'll add comments to that Jira ticket as I make progress.
>>>
>>> Best regards,
>>> Remko
>>>
>>>
>>> On Sat, Feb 1, 2014 at 9:28 AM, Kireet <ki...@feedly.com> wrote:
>>>
>>> I am trying to use the rolling file appender in log4j2, basically I want
>>>> to roll at midnight daily and keep 3 old log files. New files are
>>>> created
>>>> properly, but log4j doesn't seem to be cleaning up the old files. Does
>>>> log4j only support cleanup of files within the time period? Here is the
>>>> relevant portion of the config. I tried things with and without the %i
>>>> pattern.
>>>>
>>>> <RollingFile name="Event" fileName="app.log"
>>>> filePattern="app-%d{yyyy-MM-dd}.%i.log">
>>>> <PatternLayout>
>>>> <Pattern>%m%n</Pattern>
>>>> </PatternLayout>
>>>> <Policies>
>>>> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
>>>> </Policies>
>>>> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
>>>> </RollingFile>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: rolling in log4j2
Posted by Kireet <ki...@feedly.com>.
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:
> Kireet, you can find more details on the Jira ticket but to summarize,
> you need to configure a SizeBasedTriggeringPolicy for the %i pattern to be
> useful.
> If you do so, only "max" files are kept _within the same time period_.
>
>
> On Sat, Feb 1, 2014 at 1:24 PM, Remko Popma <re...@gmail.com> wrote:
>
>> Kireet,
>>
>> I can reproduce this and I've raised
>> https://issues.apache.org/jira/browse/LOG4J2-524 to track the issue.
>> I'll add comments to that Jira ticket as I make progress.
>>
>> Best regards,
>> Remko
>>
>>
>> On Sat, Feb 1, 2014 at 9:28 AM, Kireet <ki...@feedly.com> wrote:
>>
>>> I am trying to use the rolling file appender in log4j2, basically I want
>>> to roll at midnight daily and keep 3 old log files. New files are created
>>> properly, but log4j doesn't seem to be cleaning up the old files. Does
>>> log4j only support cleanup of files within the time period? Here is the
>>> relevant portion of the config. I tried things with and without the %i
>>> pattern.
>>>
>>> <RollingFile name="Event" fileName="app.log"
>>> filePattern="app-%d{yyyy-MM-dd}.%i.log">
>>> <PatternLayout>
>>> <Pattern>%m%n</Pattern>
>>> </PatternLayout>
>>> <Policies>
>>> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
>>> </Policies>
>>> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
>>> </RollingFile>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: rolling in log4j2
Posted by Remko Popma <re...@gmail.com>.
Kireet, you can find more details on the Jira ticket but to summarize,
you need to configure a SizeBasedTriggeringPolicy for the %i pattern to be
useful.
If you do so, only "max" files are kept _within the same time period_.
On Sat, Feb 1, 2014 at 1:24 PM, Remko Popma <re...@gmail.com> wrote:
> Kireet,
>
> I can reproduce this and I've raised
> https://issues.apache.org/jira/browse/LOG4J2-524 to track the issue.
> I'll add comments to that Jira ticket as I make progress.
>
> Best regards,
> Remko
>
>
> On Sat, Feb 1, 2014 at 9:28 AM, Kireet <ki...@feedly.com> wrote:
>
>> I am trying to use the rolling file appender in log4j2, basically I want
>> to roll at midnight daily and keep 3 old log files. New files are created
>> properly, but log4j doesn't seem to be cleaning up the old files. Does
>> log4j only support cleanup of files within the time period? Here is the
>> relevant portion of the config. I tried things with and without the %i
>> pattern.
>>
>> <RollingFile name="Event" fileName="app.log"
>> filePattern="app-%d{yyyy-MM-dd}.%i.log">
>> <PatternLayout>
>> <Pattern>%m%n</Pattern>
>> </PatternLayout>
>> <Policies>
>> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
>> </Policies>
>> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
>> </RollingFile>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
Re: rolling in log4j2
Posted by Remko Popma <re...@gmail.com>.
Kireet,
I can reproduce this and I've raised
https://issues.apache.org/jira/browse/LOG4J2-524 to track the issue.
I'll add comments to that Jira ticket as I make progress.
Best regards,
Remko
On Sat, Feb 1, 2014 at 9:28 AM, Kireet <ki...@feedly.com> wrote:
> I am trying to use the rolling file appender in log4j2, basically I want
> to roll at midnight daily and keep 3 old log files. New files are created
> properly, but log4j doesn't seem to be cleaning up the old files. Does
> log4j only support cleanup of files within the time period? Here is the
> relevant portion of the config. I tried things with and without the %i
> pattern.
>
> <RollingFile name="Event" fileName="app.log"
> filePattern="app-%d{yyyy-MM-dd}.%i.log">
> <PatternLayout>
> <Pattern>%m%n</Pattern>
> </PatternLayout>
> <Policies>
> <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
> </Policies>
> <DefaultRolloverStrategy compressionLevel="0" max="3"/>
> </RollingFile>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>