You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Robin Beetge@iCommerce" <ro...@za.didata.com> on 2001/07/24 15:52:53 UTC
DailyRollingFileAppender problems
Hi
I am having the following problem with the DailyRollingFileAppender and was
wondering if this was a bug or whether the behaviour is as it should be.
When using the DailyRollingFileAppender set so that it rolls over every
minute it will only work if I have a program that runs for more than a
minute a writes messages in each of the two minutes that the program spans.
But if I have a quick program that writes a single log message and run it at
say 13H00 and again at 13H05 then both messages are in the same file i.e. no
roll over occurs.
I went through the source code and swithced the debugging for log4j on and
confirmed that the code should be operating as above, hence my question
whether this is by design.
I would have expected DailyRollingFileAppender to work as with
RollingFileAppender that will check the file if it is written to from to
seperate programs at different times. i.e. check the timestamp on the file
before writing to it if before the next roll over time write else roll over
and then write
I can see that my way would incur a greater time wastage as you'd have to
check the file each time you start up.
hope I make sense.
thanks for the help
Robin Beetge
Systems Developer
Dimension Data i-Commerce Services
Tel. (021) 9367766
Cell 082 3751665
e-Mail: Robin.Beetge@za.didata.com
Web www.didata.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
RE: DailyRollingFileAppender problems
Posted by Jon Arnett <ja...@tconl.com>.
Ceki,
I worried about the non-existent file problem also, but discovered that the
file is guaranteed to already be open by the time the activateOptions method
is called. I couldn't believe the fix was so simple, and yet seems to be
bulletproof. I can't say that I've run an extreme battery of tests against
the fix, but I have tried most of the obvious ones without running into any
problems. I came up with the fix idea without spending much time looking at
the code to understand how everything works. Then I just ran different
scenarios in the debugger to make sure the fix worked. It's better to be
lucky than good, or so they say... :)
-jon
-----Original Message-----
From: Ceki Gülcü [mailto:cgu@qos.ch]
Sent: Wednesday, July 25, 2001 2:08 PM
To: LOG4J Developers Mailing List
Subject: RE: DailyRollingFileAppender problems
Jon,
Frighteningly simple indeed. :-)
What happens if the file named "filename" does not exist? The scheduled file
will be dated 1/1/1970. Hardly what we want. Otherwise, this is the nicest
solution I have seen so far. Regards, Ceki
At 10:07 25.07.2001 -0500, you wrote:
>Actually it doesn't change the name of the current file, just the scheduled
>filename. It works exactly like the other version, except correctly. ;-)
>
>-jon
>-----Original Message-----
>From: Ceki Gülcü [mailto:cgu@qos.ch]
>Sent: Wednesday, July 25, 2001 1:56 AM
>To: LOG4J Developers Mailing List
>Subject: RE: DailyRollingFileAppender problems
>
>
>This also changes the name of the current file. Something we do not want to
>do. Regards, Ceki
>
>At 21:23 24.07.2001 -0500, Jon Arnett wrote:
>>The fix is frighteningly simple; there's an initialization bug in
>>DailyRollingFileAppender.java. The fix goes into the activateOptions()
>>method as demonstrated below:
>>
>> public
>> void activateOptions() {
>> super.activateOptions();
>> if(datePattern != null && fileName != null) {
>> now.setTime(System.currentTimeMillis());
>> sdf = new SimpleDateFormat(datePattern);
>> int type = computeCheckPeriod();
>> printPeriodicity(type);
>> rc.setType(type);
>>// ****************************************
>>// The bug is fixed in the following line. Instead of
>>"filename+sdf.format(new Date())", use the following:
>> scheduledFilename =
>> fileName+sdf.format(new Date(new File(fileName).lastModified()));
>>// ****************************************
>> } else {
>> LogLog.error("Either Filename or DatePattern options are not set for
>>["+
>> name+"].");
>> }
>> }
>>
>>I posted the patch a few weeks ago, but never heard anything back.
>>
>>-jon
>>-----Original Message-----
>>From: Kevin Steppe [mailto:ksteppe@pacbell.net]
>>Sent: Tuesday, July 24, 2001 2:07 PM
>>To: LOG4J Developers Mailing List
>>Subject: Re: DailyRollingFileAppender problems
>>
>>Robin,
>> This is a known feature/bug for the DailyRollingFileAppender. You
have
>>two
>>options to get around this. First in the cvs is a
CompositeRollingAppender
>>which will do this for you -- you could also use it as a
>RollingFileAppender
>>or
>>combined, hence Composite. Second, a few weeks back someone posted a
>>different
>>solution that checks and rolls old files.
>>
>>Kevin
>>
>>
>>"Robin Beetge@iCommerce" wrote:
>>
>>> Hi
>>>
>>> I am having the following problem with the DailyRollingFileAppender and
>>was
>>> wondering if this was a bug or whether the behaviour is as it should be.
>>> When using the DailyRollingFileAppender set so that it rolls over every
>>> minute it will only work if I have a program that runs for more than a
>>> minute a writes messages in each of the two minutes that the program
>>spans.
>>> But if I have a quick program that writes a single log message and run
it
>>at
>>> say 13H00 and again at 13H05 then both messages are in the same file
i.e.
>>no
>>> roll over occurs.
>>>
>>> I went through the source code and swithced the debugging for log4j on
>and
>>> confirmed that the code should be operating as above, hence my question
>>> whether this is by design.
>>> I would have expected DailyRollingFileAppender to work as with
>>> RollingFileAppender that will check the file if it is written to from to
>>> seperate programs at different times. i.e. check the timestamp on the
>file
>>> before writing to it if before the next roll over time write else roll
>>over
>>> and then write
>>>
>>> I can see that my way would incur a greater time wastage as you'd have
to
>>> check the file each time you start up.
>>>
>>> hope I make sense.
>>> thanks for the help
>>>
>>> Robin Beetge
>>> Systems Developer
>>> Dimension Data i-Commerce Services
>>> Tel. (021) 9367766
>>> Cell 082 3751665
>>> e-Mail: Robin.Beetge@za.didata.com
>>> Web www.didata.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
RE: DailyRollingFileAppender problems
Posted by Ceki Gülcü <cg...@qos.ch>.
Jon,
Frighteningly simple indeed. :-)
What happens if the file named "filename" does not exist? The scheduled file will be dated 1/1/1970. Hardly what we want. Otherwise, this is the nicest solution I have seen so far. Regards, Ceki
At 10:07 25.07.2001 -0500, you wrote:
>Actually it doesn't change the name of the current file, just the scheduled
>filename. It works exactly like the other version, except correctly. ;-)
>
>-jon
>-----Original Message-----
>From: Ceki Gülcü [mailto:cgu@qos.ch]
>Sent: Wednesday, July 25, 2001 1:56 AM
>To: LOG4J Developers Mailing List
>Subject: RE: DailyRollingFileAppender problems
>
>
>This also changes the name of the current file. Something we do not want to
>do. Regards, Ceki
>
>At 21:23 24.07.2001 -0500, Jon Arnett wrote:
>>The fix is frighteningly simple; there's an initialization bug in
>>DailyRollingFileAppender.java. The fix goes into the activateOptions()
>>method as demonstrated below:
>>
>> public
>> void activateOptions() {
>> super.activateOptions();
>> if(datePattern != null && fileName != null) {
>> now.setTime(System.currentTimeMillis());
>> sdf = new SimpleDateFormat(datePattern);
>> int type = computeCheckPeriod();
>> printPeriodicity(type);
>> rc.setType(type);
>>// ****************************************
>>// The bug is fixed in the following line. Instead of
>>"filename+sdf.format(new Date())", use the following:
>> scheduledFilename =
>> fileName+sdf.format(new Date(new File(fileName).lastModified()));
>>// ****************************************
>> } else {
>> LogLog.error("Either Filename or DatePattern options are not set for
>>["+
>> name+"].");
>> }
>> }
>>
>>I posted the patch a few weeks ago, but never heard anything back.
>>
>>-jon
>>-----Original Message-----
>>From: Kevin Steppe [mailto:ksteppe@pacbell.net]
>>Sent: Tuesday, July 24, 2001 2:07 PM
>>To: LOG4J Developers Mailing List
>>Subject: Re: DailyRollingFileAppender problems
>>
>>Robin,
>> This is a known feature/bug for the DailyRollingFileAppender. You have
>>two
>>options to get around this. First in the cvs is a CompositeRollingAppender
>>which will do this for you -- you could also use it as a
>RollingFileAppender
>>or
>>combined, hence Composite. Second, a few weeks back someone posted a
>>different
>>solution that checks and rolls old files.
>>
>>Kevin
>>
>>
>>"Robin Beetge@iCommerce" wrote:
>>
>>> Hi
>>>
>>> I am having the following problem with the DailyRollingFileAppender and
>>was
>>> wondering if this was a bug or whether the behaviour is as it should be.
>>> When using the DailyRollingFileAppender set so that it rolls over every
>>> minute it will only work if I have a program that runs for more than a
>>> minute a writes messages in each of the two minutes that the program
>>spans.
>>> But if I have a quick program that writes a single log message and run it
>>at
>>> say 13H00 and again at 13H05 then both messages are in the same file i.e.
>>no
>>> roll over occurs.
>>>
>>> I went through the source code and swithced the debugging for log4j on
>and
>>> confirmed that the code should be operating as above, hence my question
>>> whether this is by design.
>>> I would have expected DailyRollingFileAppender to work as with
>>> RollingFileAppender that will check the file if it is written to from to
>>> seperate programs at different times. i.e. check the timestamp on the
>file
>>> before writing to it if before the next roll over time write else roll
>>over
>>> and then write
>>>
>>> I can see that my way would incur a greater time wastage as you'd have to
>>> check the file each time you start up.
>>>
>>> hope I make sense.
>>> thanks for the help
>>>
>>> Robin Beetge
>>> Systems Developer
>>> Dimension Data i-Commerce Services
>>> Tel. (021) 9367766
>>> Cell 082 3751665
>>> e-Mail: Robin.Beetge@za.didata.com
>>> Web www.didata.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
RE: DailyRollingFileAppender problems
Posted by Jon Arnett <ja...@tconl.com>.
Actually it doesn't change the name of the current file, just the scheduled
filename. It works exactly like the other version, except correctly. ;-)
-jon
-----Original Message-----
From: Ceki Gülcü [mailto:cgu@qos.ch]
Sent: Wednesday, July 25, 2001 1:56 AM
To: LOG4J Developers Mailing List
Subject: RE: DailyRollingFileAppender problems
This also changes the name of the current file. Something we do not want to
do. Regards, Ceki
At 21:23 24.07.2001 -0500, Jon Arnett wrote:
>The fix is frighteningly simple; there's an initialization bug in
>DailyRollingFileAppender.java. The fix goes into the activateOptions()
>method as demonstrated below:
>
> public
> void activateOptions() {
> super.activateOptions();
> if(datePattern != null && fileName != null) {
> now.setTime(System.currentTimeMillis());
> sdf = new SimpleDateFormat(datePattern);
> int type = computeCheckPeriod();
> printPeriodicity(type);
> rc.setType(type);
>// ****************************************
>// The bug is fixed in the following line. Instead of
>"filename+sdf.format(new Date())", use the following:
> scheduledFilename =
> fileName+sdf.format(new Date(new File(fileName).lastModified()));
>// ****************************************
> } else {
> LogLog.error("Either Filename or DatePattern options are not set for
>["+
> name+"].");
> }
> }
>
>I posted the patch a few weeks ago, but never heard anything back.
>
>-jon
>-----Original Message-----
>From: Kevin Steppe [mailto:ksteppe@pacbell.net]
>Sent: Tuesday, July 24, 2001 2:07 PM
>To: LOG4J Developers Mailing List
>Subject: Re: DailyRollingFileAppender problems
>
>Robin,
> This is a known feature/bug for the DailyRollingFileAppender. You have
>two
>options to get around this. First in the cvs is a CompositeRollingAppender
>which will do this for you -- you could also use it as a
RollingFileAppender
>or
>combined, hence Composite. Second, a few weeks back someone posted a
>different
>solution that checks and rolls old files.
>
>Kevin
>
>
>"Robin Beetge@iCommerce" wrote:
>
>> Hi
>>
>> I am having the following problem with the DailyRollingFileAppender and
>was
>> wondering if this was a bug or whether the behaviour is as it should be.
>> When using the DailyRollingFileAppender set so that it rolls over every
>> minute it will only work if I have a program that runs for more than a
>> minute a writes messages in each of the two minutes that the program
>spans.
>> But if I have a quick program that writes a single log message and run it
>at
>> say 13H00 and again at 13H05 then both messages are in the same file i.e.
>no
>> roll over occurs.
>>
>> I went through the source code and swithced the debugging for log4j on
and
>> confirmed that the code should be operating as above, hence my question
>> whether this is by design.
>> I would have expected DailyRollingFileAppender to work as with
>> RollingFileAppender that will check the file if it is written to from to
>> seperate programs at different times. i.e. check the timestamp on the
file
>> before writing to it if before the next roll over time write else roll
>over
>> and then write
>>
>> I can see that my way would incur a greater time wastage as you'd have to
>> check the file each time you start up.
>>
>> hope I make sense.
>> thanks for the help
>>
>> Robin Beetge
>> Systems Developer
>> Dimension Data i-Commerce Services
>> Tel. (021) 9367766
>> Cell 082 3751665
>> e-Mail: Robin.Beetge@za.didata.com
>> Web www.didata.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
RE: DailyRollingFileAppender problems
Posted by Ceki Gülcü <cg...@qos.ch>.
This also changes the name of the current file. Something we do not want to do. Regards, Ceki
At 21:23 24.07.2001 -0500, Jon Arnett wrote:
>The fix is frighteningly simple; there's an initialization bug in
>DailyRollingFileAppender.java. The fix goes into the activateOptions()
>method as demonstrated below:
>
> public
> void activateOptions() {
> super.activateOptions();
> if(datePattern != null && fileName != null) {
> now.setTime(System.currentTimeMillis());
> sdf = new SimpleDateFormat(datePattern);
> int type = computeCheckPeriod();
> printPeriodicity(type);
> rc.setType(type);
>// ****************************************
>// The bug is fixed in the following line. Instead of
>"filename+sdf.format(new Date())", use the following:
> scheduledFilename =
> fileName+sdf.format(new Date(new File(fileName).lastModified()));
>// ****************************************
> } else {
> LogLog.error("Either Filename or DatePattern options are not set for
>["+
> name+"].");
> }
> }
>
>I posted the patch a few weeks ago, but never heard anything back.
>
>-jon
>-----Original Message-----
>From: Kevin Steppe [mailto:ksteppe@pacbell.net]
>Sent: Tuesday, July 24, 2001 2:07 PM
>To: LOG4J Developers Mailing List
>Subject: Re: DailyRollingFileAppender problems
>
>Robin,
> This is a known feature/bug for the DailyRollingFileAppender. You have
>two
>options to get around this. First in the cvs is a CompositeRollingAppender
>which will do this for you -- you could also use it as a RollingFileAppender
>or
>combined, hence Composite. Second, a few weeks back someone posted a
>different
>solution that checks and rolls old files.
>
>Kevin
>
>
>"Robin Beetge@iCommerce" wrote:
>
>> Hi
>>
>> I am having the following problem with the DailyRollingFileAppender and
>was
>> wondering if this was a bug or whether the behaviour is as it should be.
>> When using the DailyRollingFileAppender set so that it rolls over every
>> minute it will only work if I have a program that runs for more than a
>> minute a writes messages in each of the two minutes that the program
>spans.
>> But if I have a quick program that writes a single log message and run it
>at
>> say 13H00 and again at 13H05 then both messages are in the same file i.e.
>no
>> roll over occurs.
>>
>> I went through the source code and swithced the debugging for log4j on and
>> confirmed that the code should be operating as above, hence my question
>> whether this is by design.
>> I would have expected DailyRollingFileAppender to work as with
>> RollingFileAppender that will check the file if it is written to from to
>> seperate programs at different times. i.e. check the timestamp on the file
>> before writing to it if before the next roll over time write else roll
>over
>> and then write
>>
>> I can see that my way would incur a greater time wastage as you'd have to
>> check the file each time you start up.
>>
>> hope I make sense.
>> thanks for the help
>>
>> Robin Beetge
>> Systems Developer
>> Dimension Data i-Commerce Services
>> Tel. (021) 9367766
>> Cell 082 3751665
>> e-Mail: Robin.Beetge@za.didata.com
>> Web www.didata.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
RE: DailyRollingFileAppender problems
Posted by Jon Arnett <ja...@tconl.com>.
The fix is frighteningly simple; there's an initialization bug in
DailyRollingFileAppender.java. The fix goes into the activateOptions()
method as demonstrated below:
public
void activateOptions() {
super.activateOptions();
if(datePattern != null && fileName != null) {
now.setTime(System.currentTimeMillis());
sdf = new SimpleDateFormat(datePattern);
int type = computeCheckPeriod();
printPeriodicity(type);
rc.setType(type);
// ****************************************
// The bug is fixed in the following line. Instead of
"filename+sdf.format(new Date())", use the following:
scheduledFilename =
fileName+sdf.format(new Date(new File(fileName).lastModified()));
// ****************************************
} else {
LogLog.error("Either Filename or DatePattern options are not set for
["+
name+"].");
}
}
I posted the patch a few weeks ago, but never heard anything back.
-jon
-----Original Message-----
From: Kevin Steppe [mailto:ksteppe@pacbell.net]
Sent: Tuesday, July 24, 2001 2:07 PM
To: LOG4J Developers Mailing List
Subject: Re: DailyRollingFileAppender problems
Robin,
This is a known feature/bug for the DailyRollingFileAppender. You have
two
options to get around this. First in the cvs is a CompositeRollingAppender
which will do this for you -- you could also use it as a RollingFileAppender
or
combined, hence Composite. Second, a few weeks back someone posted a
different
solution that checks and rolls old files.
Kevin
"Robin Beetge@iCommerce" wrote:
> Hi
>
> I am having the following problem with the DailyRollingFileAppender and
was
> wondering if this was a bug or whether the behaviour is as it should be.
> When using the DailyRollingFileAppender set so that it rolls over every
> minute it will only work if I have a program that runs for more than a
> minute a writes messages in each of the two minutes that the program
spans.
> But if I have a quick program that writes a single log message and run it
at
> say 13H00 and again at 13H05 then both messages are in the same file i.e.
no
> roll over occurs.
>
> I went through the source code and swithced the debugging for log4j on and
> confirmed that the code should be operating as above, hence my question
> whether this is by design.
> I would have expected DailyRollingFileAppender to work as with
> RollingFileAppender that will check the file if it is written to from to
> seperate programs at different times. i.e. check the timestamp on the file
> before writing to it if before the next roll over time write else roll
over
> and then write
>
> I can see that my way would incur a greater time wastage as you'd have to
> check the file each time you start up.
>
> hope I make sense.
> thanks for the help
>
> Robin Beetge
> Systems Developer
> Dimension Data i-Commerce Services
> Tel. (021) 9367766
> Cell 082 3751665
> e-Mail: Robin.Beetge@za.didata.com
> Web www.didata.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: DailyRollingFileAppender problems
Posted by Kevin Steppe <ks...@pacbell.net>.
Robin,
This is a known feature/bug for the DailyRollingFileAppender. You have two
options to get around this. First in the cvs is a CompositeRollingAppender
which will do this for you -- you could also use it as a RollingFileAppender or
combined, hence Composite. Second, a few weeks back someone posted a different
solution that checks and rolls old files.
Kevin
"Robin Beetge@iCommerce" wrote:
> Hi
>
> I am having the following problem with the DailyRollingFileAppender and was
> wondering if this was a bug or whether the behaviour is as it should be.
> When using the DailyRollingFileAppender set so that it rolls over every
> minute it will only work if I have a program that runs for more than a
> minute a writes messages in each of the two minutes that the program spans.
> But if I have a quick program that writes a single log message and run it at
> say 13H00 and again at 13H05 then both messages are in the same file i.e. no
> roll over occurs.
>
> I went through the source code and swithced the debugging for log4j on and
> confirmed that the code should be operating as above, hence my question
> whether this is by design.
> I would have expected DailyRollingFileAppender to work as with
> RollingFileAppender that will check the file if it is written to from to
> seperate programs at different times. i.e. check the timestamp on the file
> before writing to it if before the next roll over time write else roll over
> and then write
>
> I can see that my way would incur a greater time wastage as you'd have to
> check the file each time you start up.
>
> hope I make sense.
> thanks for the help
>
> Robin Beetge
> Systems Developer
> Dimension Data i-Commerce Services
> Tel. (021) 9367766
> Cell 082 3751665
> e-Mail: Robin.Beetge@za.didata.com
> Web www.didata.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Another solution for DailyRollingFileAppender
Posted by David Owens <do...@synxis.com>.
All,
A while back I created a TimeRollingFileAppender (Before the creation of the
DailyRollingFileAppender). I was ready to rip mine out and use the
Daily version
but we needed to roll at specific times, like 5 past the hour etc... in
addition, there is
a problem when to VMs are writing/rolling the same file which causes all
kinds of
strange looking log files. So, I have updated, maintained, and
continued to use the
TimeRollingFileAppender. I thought I should send it out there and see
if any of you
thought it might be useful. It's key features are as follows:
-Allows rolling to occure at any specific time defined to the second.
-Allows rolling at any interval defined to the minute.
-Allows custom time stamping defined by a java DateFormat
-Takes care of multiple VMs writing to and rolling the log file.
It probably lacks some features that the DailyRollingFileAppender has,
but perhaps if
it is worthy we could create a hybrid.
Anyway, here it is for your review...
|)ave