logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Powers" <mpow...@appsecinc.com>
Subject RE: rollingfileappender ... not rolling?
Date Tue, 17 Apr 2007 14:42:53 GMT
This is not a multiple-process situation. It is multi-threaded, but the
logging is wrapped in some synchronized singleton class. When I built the
library, the unit tests caused some unhandled exception, but my co-worker
assured me that the libraries were OK. So maybe getting a newer version from
the repository would make things better.

 

 

Thanks,

 

Marshall

  _____  

From: log4cxx-user-return-1937-mpowers=appsecinc.com@logging.apache.org
[mailto:log4cxx-user-return-1937-mpowers=appsecinc.com@logging.apache.org]
On Behalf Of Curt Arnold
Sent: 2007-Apr-17 Tue 1:46 AM
To: Log4CXX User
Subject: Re: rollingfileappender ... not rolling?

 

 

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