logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shapira, Yoav" <Yoav.Shap...@mpi.com>
Subject RE: RFE - Fixed Memory Logging
Date Tue, 04 May 2004 12:53:54 GMT

Hi,
As I've mentioned already, fixed storage logging is available in log4j
1.2.  Use a RollingFileAppender with whatever size you want and a
MaxBackupIndex of 0.

Yoav Shapira
Millennium Research Informatics


>-----Original Message-----
>From: Alan Brown [mailto:abrown@opstechnology.com]
>Sent: Monday, May 03, 2004 7:22 PM
>To: Log4J Developers List
>Subject: RE: RFE - Fixed Memory Logging
>
>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)
>rollover()
>
>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...
>
>alan
>
>
>
>
>-----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
>particular
>Appender.  Feel free to flesh out any ideas you have on the log4j-dev
>list
>if you like.
>
>cheers,
>
>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




This e-mail, including any attachments, is a confidential business communication, and may
contain information that is confidential, proprietary and/or privileged.  This e-mail is intended
only for the individual(s) to whom it is addressed, and may not be saved, copied, printed,
disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately
delete this e-mail from your computer system and notify the sender.  Thank you.


---------------------------------------------------------------------
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