logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Enhanced FileAppender
Date Thu, 05 Oct 2006 03:33:59 GMT

On Oct 4, 2006, at 4:22 PM, Leo Lima wrote:

> Hello, Curt.
> I agree with you on almost all of them, but:
>
>> A configurable limit on the number of writers open at any one time.
>> A configurable limit on the time a writer will rename open  
>> without  any
>> writes.
>
> It would be something like 'whichever comes first, close a file  
> handler',
> right?
>

That was my thought.


>> Opening or reopening a log file will append to the file.
>
> That should be the case only if the log file was closed due timeout  
> or max
> open limit reached; because that would then mimic the behavior of
> FileAppender; the Append parameter being false, the file is  
> overwritten on
> first open...

If there is an append attribute, then it would need to follow the  
pattern that you suggest.  However, I'm not sure that their is a  
strong enough use case to support an "append" attribute.  Obviously,  
if you extend from FileAppender you would have one and would have to  
figure out what it means.  Supporting the "append" semantics that you  
described would, like header and footer, require that you capture the  
name of every file ever opened during the application lifetime.


>
>>
>> I would expect this to be derived from AppenderSkeleton or maybe
>> WriterAppender, but not FileAppender.
>
> Why not?

I don't think that FileAppender would have the right extension points  
and the file attribute would be ignored or some fallback semantic  
would have to be defined for it.

>
>>
>> I like the name MultiFileAppender at the moment.
>>
>> Headers and Footers might be interesting.  I think you'd only  
>> write  the
>> header when the file does not exist.  I think you would not want   
>> to write
>> the footer when a file was closed due to max open files or   
>> elapsed time,
>> which might mean keeping around a list of file names  that had been
>> encountered and writing the footers when the overall  appender was  
>> closed.
>> Or maybe not support headers/footers at al.
>
> I think not supporting is better, avoiding many complications...
>

Headers and Footers are part of the layout, so you could not prevent  
the user from matching a MultiFileAppender with a layout with a  
header or footer.  However, explicitly saying that you ignore them  
would be an option, at least at first.


>>
>> I would not suggest using a thread to monitor the elapsed time,  
>> but  just
>> check the map of writers on each log request.
>
> The problem of not using a thread would be that, if the system is not
> generating new log events, the writer would never timeout, thus  
> failing to
> do what it was supposed to do. I guess that the problem we (I do,  
> at least)
> face is too many open files; that would be solved using the 'A  
> configurable
> limit on the number of writers open at any one time.' you  
> suggested. It
> would them eliminate the oldest (or least on average? which  
> strategy is
> better?) open, close it and generate a new. This way, we avoid 'max  
> open
> files' errors and don't have to have a thread checking, nor check  
> on each
> log event: check only when creating a new file. That could be done  
> using a
> pool of some sort...

At least not use a thread to manage it by default.  Maybe an optional  
parameter to specify a timer interval or an public method that an  
interested user could add to a scheduler.


>
> My 2 cents.
>
> Best regards,
> Leo.



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message