logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: rollingfileappender ... not rolling?
Date Tue, 17 Apr 2007 05:46:20 GMT

On Apr 16, 2007, at 1:01 PM, Marshall Powers wrote:

> Running on winxp 32 bit. I haven’t really looked into the unit  
> tests. How do I run the unit test to verify the rolling file  
> appender behavior?
>
>
>
> Marshall
>
>

The Ant build should run the size-based tests as part of the build  
process.  If you look in tests\output, you should see several files  
named sizeBased-test*.*, most of which should be 100 bytes long.

If you want to run it manually, do something like:

cd tests
path ..\build\debug\shared;c:\cygwin\bin;%PATH%
log4cxx-test SizeBasedRollingTest

If any other process has a lock on the file, it will prevent  
rolling.  Having multiple processes write to the same log file is  
unsupported and strongly discouraged in either log4j or log4cxx.

Are you using a fairly recent snapshot of log4cxx from SVN?

I may be mangling issues from log4j and log4cxx together, but I think  
the following is essential right for both.  The file size operations  
on closed files will give accurate file sizes, but attempting to get  
the file size on a open file may not reflect the current size of the  
file (I think it is typically correct for Unix's and stays at the  
initial size on Windows).  To keep track of the current size of the  
file, the number of bytes written is monitored and when log4cxx  
predicts the file has crossed a size boundary, the file will roll.   
This will break down if multiple processes are writing to the file or  
there is other out of band changes to the file as log4cxx will not  
see the other activity.  Both log4j and log4cxx failed on Windows  
earlier and if you are using an old copy, then you may still be  
depending on the file size reported by the OS.









Mime
View raw message