From log4j-user-return-25519-apmail-logging-log4j-user-archive=logging.apache.org@logging.apache.org Sun Feb 2 07:01:19 2014 Return-Path: X-Original-To: apmail-logging-log4j-user-archive@www.apache.org Delivered-To: apmail-logging-log4j-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4650FCF48 for ; Sun, 2 Feb 2014 07:01:19 +0000 (UTC) Received: (qmail 93720 invoked by uid 500); 2 Feb 2014 07:01:18 -0000 Delivered-To: apmail-logging-log4j-user-archive@logging.apache.org Received: (qmail 93263 invoked by uid 500); 2 Feb 2014 07:01:06 -0000 Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Users List" Reply-To: "Log4J Users List" Delivered-To: mailing list log4j-user@logging.apache.org Received: (qmail 93245 invoked by uid 99); 2 Feb 2014 07:01:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Feb 2014 07:01:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of garydgregory@gmail.com designates 209.85.214.43 as permitted sender) Received: from [209.85.214.43] (HELO mail-bk0-f43.google.com) (209.85.214.43) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Feb 2014 07:00:56 +0000 Received: by mail-bk0-f43.google.com with SMTP id mx11so2579151bkb.16 for ; Sat, 01 Feb 2014 23:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=P6kJdb12FTQlRO4tuGkf0mVee9uz6fHhLmigVFg/FTc=; b=ygLuu/h84d7wzRTknL9/YvrwzCMUqCtTmekmWaJXYGOG4qIDzHXw284IJyRq/GAtHq msJSWEkvckF8aoW/L7akDbUCXBcOsw8nVAywevQxfV1wtJsn6o1Qlt/vXq5IoiPYX6qF n4BhqE4VvunHZ3DT8eqF6j/Pt5h2YxFak+hPY7mRfEEQDeoDHqYyo9FqyvtyU/GUzKXL JEMrIZScEBt0xYap3W6uXe7uYJ04fyySQqo/55u8DC3T/K7Upo8d0Iry8hqvk90jK5lu uQ2dmvWk3xSKXLv3rQ8XLMormyyJfktNZQ60u/I1YOP5uy654Qi+YBubfY91IQoZqM1p gEUw== MIME-Version: 1.0 X-Received: by 10.204.80.78 with SMTP id s14mr8597851bkk.6.1391324435784; Sat, 01 Feb 2014 23:00:35 -0800 (PST) Received: by 10.204.102.201 with HTTP; Sat, 1 Feb 2014 23:00:35 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Feb 2014 02:00:35 -0500 Message-ID: Subject: Re: rolling in log4j2 From: Gary Gregory To: Log4J Users List Content-Type: multipart/alternative; boundary=047d7bdc915cc3575204f166f6ce X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdc915cc3575204f166f6ce Content-Type: text/plain; charset=UTF-8 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 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 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 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 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 > > >>> > >>> 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 >>>>> 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 >>>>>> ;>> > >>>>>> > >>>>> 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. > >>>>>>> > >>>>>>> >>>>>>> filePattern="app-%d{yyyy-MM-dd}.%i.log"> > >>>>>>> > >>>>>>> %m%n > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ------------------------------------------------------------ > >>>>>>> --------- > >>>>>>> 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 > >>>> > >>>> > >>>> > >>>> > >>> > >> > > > > --------------------------------------------------------------------- > > 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 JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --047d7bdc915cc3575204f166f6ce--