Hi Curt, > -----Original Message----- > From: Curt Arnold [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
