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.
