You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Marshall Powers <mp...@appsecinc.com> on 2007/04/16 19:12:04 UTC
rollingfileappender ... not rolling?
I'm trying to use a RollingFileAppender, but my log files are not "rolling"
when it seems that they should. I am using a SizeBasedTriggeringPolicy with
max file size = 100kb, and a FixedWindowRollingPolicy. When I start my
program, if a log file already exists that is larger than the max file size,
it gets backed up properly, but when my log file runs over 100kb during the
normal run of the program, it simply keeps growing, it doesn't roll over. Is
this the desired behavior of these classes? The fact that it does roll the
log files at startup suggests that I have it almost right, but either I have
a mistaken idea about how the appender is supposed to work, or I am missing
some subtle step. Any ideas?
Thanks
Marshall
RE: rollingfileappender ... not rolling?
Posted by Marshall Powers <mp...@appsecinc.com>.
Ok I found the problem. It had nothing to do with log4cxx after all, its
just that the initialization code for the logger set the default max file
size with a value measured in kilobytes, which was later overwritten by a
value from the config file measured in bytes. So if I had had the patience
to wait for my "100kb" logs to grow to 100mb, I would have seen the correct
behavior of the rollingfileappender after all.
Sorry for the confusion,
Marshall
_____
From: log4cxx-user-return-1941-mpowers=appsecinc.com@logging.apache.org
[mailto:log4cxx-user-return-1941-mpowers=appsecinc.com@logging.apache.org]
On Behalf Of Curt Arnold
Sent: 2007-Apr-17 Tue 1:36 PM
To: Log4CXX User
Subject: Re: rollingfileappender ... not rolling?
On Apr 17, 2007, at 11:15 AM, Marshall Powers wrote:
I tried running the unit tests, as you suggested, and they appeared to work
fine. For kicks, I tried reducing the max file size of my
SizeBasedTriggeringPolicy to 100 bytes, as in the test case. What I saw was
when my application started, it quickly generated several log files of 100
bytes like foo.0.log, foo.1.log, etc, but at some point the TriggeringPolicy
stopped working, leaving me with a foo.0.log file of about 50kb and growing.
Do you think this confirms the weird file-size reporting problem you were
talking about before?
Thanks,
Marshall
Doesn't sound like the file-size reporting problem or it wouldn't hit the
byte counts. I'm guessing that the triggering policy is still requesting
rollovers, it is just that the FixedWindowRollingPolicy is failing to delete
the oldest log file and is abandoning the attempted rollover. The number of
retained rollovered files is 7 (with an max of 12) once those are filled up,
the oldest is deleted (line 233 of fixedwindowrollingpolicy) so the rest can
be renamed. In your experiment did you get 7 rollovered files? Are you able
to delete the oldest? I don't think there is a unit test that checks the
behavior once you start hitting the max number of files (I'll have to
check).
ODP: rollingfileappender ... not rolling?
Posted by Matthieu Le Brun <ma...@comarch.pl>.
Hi,
concerning this limit of 7 and max of 12 rollovered files, is there a special
reason for it ? If we need to keep more than 12 files, should we modify the code
by ourself ? It seems strange to me that there is a hardcoded limit, so there
may be a reason I'm not aware of...
Thanks,
Matthieu
-----------------------------------------------------
Comarch Software AG;
Chemnitzer Str. 50; 01187 Dresden
Tel.: +49 351 4389 700; Fax: +49 351 4389 710
Registriert beim Amtsgericht Dresden HRB 23838
Vorstand: Anna Filipiak; Vorsitz: Katharina Bania, Tomasz Brodziak
Aufsichtsrat: Janusz Filipiak; Vorsitz: Rafal Chwast, Pawel Przewiezlikowski
_____
Od: Curt Arnold [mailto:carnold@apache.org]
Wysłano: 17 kwietnia 2007 19:36
Do: Log4CXX User
Temat: Re: rollingfileappender ... not rolling?
On Apr 17, 2007, at 11:15 AM, Marshall Powers wrote:
I tried running the unit tests, as you suggested, and they appeared to work
fine. For kicks, I tried reducing the max file size of my
SizeBasedTriggeringPolicy to 100 bytes, as in the test case. What I saw was when
my application started, it quickly generated several log files of 100 bytes like
foo.0.log, foo.1.log, etc, but at some point the TriggeringPolicy stopped
working, leaving me with a foo.0.log file of about 50kb and growing. Do you
think this confirms the weird file-size reporting problem you were talking about
before?
Thanks,
Marshall
Doesn't sound like the file-size reporting problem or it wouldn't hit the byte
counts. I'm guessing that the triggering policy is still requesting rollovers,
it is just that the FixedWindowRollingPolicy is failing to delete the oldest log
file and is abandoning the attempted rollover. The number of retained rollovered
files is 7 (with an max of 12) once those are filled up, the oldest is deleted
(line 233 of fixedwindowrollingpolicy) so the rest can be renamed. In your
experiment did you get 7 rollovered files? Are you able to delete the oldest? I
don't think there is a unit test that checks the behavior once you start hitting
the max number of files (I'll have to check).
Re: rollingfileappender ... not rolling?
Posted by Curt Arnold <ca...@apache.org>.
On Apr 17, 2007, at 11:15 AM, Marshall Powers wrote:
> I tried running the unit tests, as you suggested, and they appeared
> to work fine. For kicks, I tried reducing the max file size of my
> SizeBasedTriggeringPolicy to 100 bytes, as in the test case. What I
> saw was when my application started, it quickly generated several
> log files of 100 bytes like foo.0.log, foo.1.log, etc, but at some
> point the TriggeringPolicy stopped working, leaving me with a foo.
> 0.log file of about 50kb and growing. Do you think this confirms
> the weird file-size reporting problem you were talking about before?
>
> Thanks,
>
> Marshall
>
>
Doesn't sound like the file-size reporting problem or it wouldn't hit
the byte counts. I'm guessing that the triggering policy is still
requesting rollovers, it is just that the FixedWindowRollingPolicy is
failing to delete the oldest log file and is abandoning the attempted
rollover. The number of retained rollovered files is 7 (with an max
of 12) once those are filled up, the oldest is deleted (line 233 of
fixedwindowrollingpolicy) so the rest can be renamed. In your
experiment did you get 7 rollovered files? Are you able to delete
the oldest? I don't think there is a unit test that checks the
behavior once you start hitting the max number of files (I'll have to
check).
RE: rollingfileappender ... not rolling?
Posted by Marshall Powers <mp...@appsecinc.com>.
I tried running the unit tests, as you suggested, and they appeared to work
fine. For kicks, I tried reducing the max file size of my
SizeBasedTriggeringPolicy to 100 bytes, as in the test case. What I saw was
when my application started, it quickly generated several log files of 100
bytes like foo.0.log, foo.1.log, etc, but at some point the TriggeringPolicy
stopped working, leaving me with a foo.0.log file of about 50kb and growing.
Do you think this confirms the weird file-size reporting problem you were
talking about before?
Thanks,
Marshall
_____
From: log4cxx-user-return-1939-mpowers=appsecinc.com@logging.apache.org
[mailto:log4cxx-user-return-1939-mpowers=appsecinc.com@logging.apache.org]
On Behalf Of Curt Arnold
Sent: 2007-Apr-17 Tue 11:52 AM
To: Log4CXX User
Subject: Re: rollingfileappender ... not rolling?
On Apr 17, 2007, at 9:42 AM, Marshall Powers wrote:
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
Building on VC 6 will produce some test failures in PatternParserTestCase or
FileNamePatternTestCase that do not occur in VC 7 or later versions and has
not been observed with any other compiler. Never been able to find a
workaround of what appears to be a compiler or run-time library bug. I
believe the tests are checking abnormal cases, so the problems with VC 6
should not affect actual use of log4cxx.
Re: rollingfileappender ... not rolling?
Posted by Curt Arnold <ca...@apache.org>.
On Apr 17, 2007, at 9:42 AM, Marshall Powers wrote:
> 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
Building on VC 6 will produce some test failures in
PatternParserTestCase or FileNamePatternTestCase that do not occur in
VC 7 or later versions and has not been observed with any other
compiler. Never been able to find a workaround of what appears to be
a compiler or run-time library bug. I believe the tests are checking
abnormal cases, so the problems with VC 6 should not affect actual
use of log4cxx.
RE: rollingfileappender ... not rolling?
Posted by Marshall Powers <mp...@appsecinc.com>.
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.
Re: rollingfileappender ... not rolling?
Posted by Curt Arnold <ca...@apache.org>.
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.
RE: rollingfileappender ... not rolling?
Posted by Marshall Powers <mp...@appsecinc.com>.
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
_____
From: log4cxx-user-return-1933-mpowers=appsecinc.com@logging.apache.org
[mailto:log4cxx-user-return-1933-mpowers=appsecinc.com@logging.apache.org]
On Behalf Of Curt Arnold
Sent: 2007-Apr-16 Mon 1:48 PM
To: Log4CXX User
Subject: Re: rollingfileappender ... not rolling?
On Apr 16, 2007, at 12:12 PM, Marshall Powers wrote:
I'm trying to use a RollingFileAppender, but my log files are not "rolling"
when it seems that they should. I am using a SizeBasedTriggeringPolicy with
max file size = 100kb, and a FixedWindowRollingPolicy. When I start my
program, if a log file already exists that is larger than the max file size,
it gets backed up properly, but when my log file runs over 100kb during the
normal run of the program, it simply keeps growing, it doesn't roll over. Is
this the desired behavior of these classes? The fact that it does roll the
log files at startup suggests that I have it almost right, but either I have
a mistaken idea about how the appender is supposed to work, or I am missing
some subtle step. Any ideas?
Strange. What platform are you running on? There are unit tests that
should check the behavior, do you know whether they passed?
Re: rollingfileappender ... not rolling?
Posted by Curt Arnold <ca...@apache.org>.
On Apr 16, 2007, at 12:12 PM, Marshall Powers wrote:
> I’m trying to use a RollingFileAppender, but my log files are not
> “rolling” when it seems that they should. I am using a
> SizeBasedTriggeringPolicy with max file size = 100kb, and a
> FixedWindowRollingPolicy. When I start my program, if a log file
> already exists that is larger than the max file size, it gets
> backed up properly, but when my log file runs over 100kb during the
> normal run of the program, it simply keeps growing, it doesn’t roll
> over. Is this the desired behavior of these classes? The fact that
> it does roll the log files at startup suggests that I have it
> almost right, but either I have a mistaken idea about how the
> appender is supposed to work, or I am missing some subtle step. Any
> ideas?
Strange. What platform are you running on? There are unit tests
that should check the behavior, do you know whether they passed?
Re: rollingfileappender ... not rolling?
Posted by Steve <kf...@gmail.com>.
Marshall Powers <mpowers <at> appsecinc.com> writes:
> I’m trying to use a RollingFileAppender, but my log
> files are not “rolling” when it seems that they should. I am using
> a SizeBasedTriggeringPolicy with max file size = 100kb, and a
> ...
>
> Thanks
>
> Marshall
Are you sharing the same log file among processes ?
I've seen this behaviour when I log all my processes to the same file.
--Steve