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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
