logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy McBride" <andy.mcbr...@dsl.pipex.com>
Subject RE: SizeBasedRollingTest failing due to output/sizeBased-test2.1 not existing
Date Thu, 21 Apr 2005 23:45:35 GMT
Hi Curt, 

> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: 21 April 2005 02:31
> To: Log4J Developers List
> Subject: Re: SizeBasedRollingTest failing due to output/sizeBased-test2.1
> not existing
> 
> Sorry to jump in so late.  I'll try to review the assert's and remember
> where they came from, I don't remember pulling them out of thin air
> (though that is always a possibility).
> 
> Updating the file metadata on Windows (FileFlushBuffers) can be an
> extraordinarily expensive operation which I found out when log4cxx
> triggered APR to call it one every append.  I think it is likely that
> force() would tend to be very expensive and obviously we would like to
> avoid depending on any IO calls that are not available in JDK 1.2 or
> 1.3.

I agree it is likely that this sort of method call would prove expensive and
appreciate that log4j not should not be dependant on 1.4+

I'm not suggesting changing the current file appender/rolling policy
implementation as it seems to have been quite satisfactory for me and many
others so far!

While the immediateFlush flag in WriterAppender protects from losing log
data in the event an application crash, this problem has highlighted the
possibility of losing log data in the event of a 'system' crash as the os
may not have written the data out to disk.  

Whilst it's not normal for a java application to crash the OS, I was
wondering if a use-case exists for this type of critical logging where it an
application needs to ensure that all info prior to the crash is secured on
disk?

I've not used nio before but curiosity compels me to try this and measure
the performance degradation :-)

> 
> Instead of depending on File.length() to monitor the length of the
> file, we could likely do a reasonable estimate by obtaining the initial
> length before opening the file (when File.length should be accurate)
> and then keep track of the number of characters written.  Given the
> fairly low frequency of non-USASCII characters in log messages, a 1:1
> character to byte ratio could be sufficient for all encodings other
> than the UTF-16's.

The decision to rollover is made before the event is rendered so wouldn't
the count always be behind when the size test is performed?

Regards

Andy

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


Mime
View raw message