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.

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.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to