On Apr 21, 2005, at 6:45 PM, Andy McBride wrote:
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 :-)
Looks challenging since you'd likely have to roll your interaction with CharsetEncoder, etc. Let us know if you find anything interesting.
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?
Likely, but the existing test is checking the file size already written so it is also deciding based on the size prior to appending the current message. I don't think it is practical to estimate the current file size within the SizeBasePolicy since it would need information from the Appender (like the encoding) to do it right. It would be better for RollingFileAppender to have the estimate, but that would suggest changing the signature of TriggeringPolicy.isTriggeringEvent or the attachment of a TriggeringPolicy to the RFA allow the trigger to interrogate the appender or pass a long instead of a File.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
