logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Brown" <abr...@opstechnology.com>
Subject RE: RFE - Fixed Memory Logging
Date Mon, 03 May 2004 23:22:00 GMT
Forgive me if this simple design doesn't fit into the design decisions
and needs of version 1.3.  It's based on the current production code,
which I've got some familiarity with.  Forgive me also if my logic is
deeply flawed or my design style repugnant. 

With that said...

My design really only applies to FileAppenders, either Rolling,
DailyRolling or, in the future, with a user defined renaming structure
and user defined rolling rules.

There appears to be 2 hooks needed in the code to do this job, one to
enable defining of when files should rollover, and another to specify
how it should be done.

An interface, (RolloverStrategy?) would have 2 methods

shouldRollover(String s) 

shouldRollover() would be called at the beginning of the subAppend()
method in the FileAppender hierarchy and would be passed the string that
would be about to be written to the logFile.  If shouldRollover()
returned true then rollover() would then be called.

This method might allow for a simplification of the RollingFileAppender
class, with some of it's current functionality put in a
BasicRolloverStrategy(?) class and an equivalent class made for the
DailyRollingFileAppender class.

I could then design a fixed storage strategy as follows:

Each RollingFileAppender would have it's own instance of my rollover
strategy class.  This would be so each rolloverStrategy class would be
rolling over to their own destinations.  However, all of these instances
would possess the same instance of a LogFileManager class, that would
hear about the length of every append in every appender (via the fact
that the shouldRollover() method will receive the length of the string
to be written and will pass it along to my global manager).  The
LogFileManager would then delete the oldest logfile in it's catalog when
the limit was reached and would keep deleting the oldest file until it
reached a second, acceptable storage usage.

When an individual strategy instance had its rollover method called, it
would pass the new file names and other pertinent info (file length, and
last modified values) to the LogFileManager class so it would always be
aware of all the files in its domain.  Finally, the LogFileManager must
be passed the log directories during instantiation so it knows the file
information for all the legacy log files.

Again, I may very well have made some egregious error in my design as it
has come from a very specific vantage point, ie, what would be the
simplest class structure would enable me to implement the functionality
for a fixedStorageFileAppender.

Comments/flames welcomed...  


-----Original Message-----
From: Paul Smith [mailto:Paul.Smith@lawlex.com.au] 
Sent: Thursday, April 29, 2004 5:31 PM
To: 'Log4J Users List'
Subject: RE: RFE - Fixed Memory Logging

> Actually, I think the title is a bit of a misnoma as it's 
> disk space I'm
> looking to cap the usage of.  
> I was wondering if anything in 1.3 would enable me to ensure 
> I won't run
> out of hard drive.  I know it's cheap and all that but, 
> depending on the
> performance cost, I'd like to be able to guarantee that I 
> won't run out
> of space if I have a sudden rush on system usage.
> What I envision is a class that would be passed the 'rolled' files and
> would keep track of them.  When the total file sizes exceed a given
> trigger value it would delete the oldest files, until the 
> size was at an
> acceptable amount.  
> Does anyone else think this would be a nice feature?

I personally think this would be an awesome feature.  It would work well
within the Plugin architecture, and be able to told to 'manage' a
Appender.  Feel free to flesh out any ideas you have on the log4j-dev
if you like.


Paul Smith

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-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message