Maximum backup index for RollingFileAppender

[Peter Steele <ps...@maxiscale.com>]

We use a RollingFileAppender defined as follows:

 

   <appender name="FILE" class="org.apache.log4j.RollingFileAppender">

       <param name="maxFileSize" value="200MB" />

       <param name="maxBackupIndex" value="20" />

       <param name="File" value="${LOGNAME}" />

       <param name="Append" value="false"/>

       <layout class="org.apache.log4j.PatternLayout">

           <param name="ConversionPattern" 

               value="%d{MM-dd HH:mm:ss.SSS} %5p %c{1} - %m%n" />

       </layout>

   </appender>

 

It works fine, except that the maxBackupIndex appears to top out at 13,
even though we have 20 specified. Are we doing something wrong or is 13
a hard coded maximum for this field?

 

Re: Maximum backup index for RollingFileAppender

[Dale King <da...@gmail.com>]

On Thu, Jul 17, 2008 at 10:25 AM, Peter Steele <ps...@maxiscale.com> wrote:
> It would have been nice if some kind of renaming scheme was used that
> was near zero-cost. For example, a date/time stamp...

You can do rolling by date time and that is part of the file name, but
then you lose the ability to delete older logs.




-- 
Dale King

RE: Maximum backup index for RollingFileAppender

[Peter Steele <ps...@maxiscale.com>]

It would have been nice if some kind of renaming scheme was used that
was near zero-cost. For example, a date/time stamp...

-----Original Message-----
From: Jostein Tveit [mailto:josteitv@pvv.ntnu.no] 
Sent: Wednesday, July 16, 2008 11:42 PM
To: Log4CXX User
Subject: Re: Maximum backup index for RollingFileAppender

"Dale King" <da...@gmail.com> writes:

> 12 is a hardcoded limit because this requires renames of all backup
> files which is expensive

It would have been nice if log4cxx issued a warning or error
message if the value was set to a value outside the boundaries.

-- 
Jostein Tveit <jo...@pvv.ntnu.no>

Re: Maximum backup index for RollingFileAppender

[Dale King <da...@gmail.com>]

On Thu, Jul 17, 2008 at 2:41 AM, Jostein Tveit <jo...@pvv.ntnu.no> wrote:
> "Dale King" <da...@gmail.com> writes:
>
>> 12 is a hardcoded limit because this requires renames of all backup
>> files which is expensive
>
> It would have been nice if log4cxx issued a warning or error
> message if the value was set to a value outside the boundaries.

Actually, it does output a message to its own internal logging
mechanism. For obvious reasons Log4Cxx cannot log to itself, so has
its own internal logging mechanism (LogLog) which outputs to stderr.
If you look at stderr you should see a message that says:

Large window sizes are not allowed.

-- 
Dale King

Re: Maximum backup index for RollingFileAppender

[Jostein Tveit <jo...@pvv.ntnu.no>]

"Dale King" <da...@gmail.com> writes:

> 12 is a hardcoded limit because this requires renames of all backup
> files which is expensive

It would have been nice if log4cxx issued a warning or error
message if the value was set to a value outside the boundaries.

-- 
Jostein Tveit <jo...@pvv.ntnu.no>

RE: Maximum backup index for RollingFileAppender

[Peter Steele <ps...@maxiscale.com>]

Yeah, I guess that makes sense. Thanks for the clarification.

-----Original Message-----
From: Dale King [mailto:dalewking@gmail.com] 
Sent: Wednesday, July 16, 2008 2:06 PM
To: Log4CXX User
Subject: Re: Maximum backup index for RollingFileAppender

On Wed, Jul 16, 2008 at 4:33 PM, Peter Steele <ps...@maxiscale.com>
wrote:
> We use a RollingFileAppender defined as follows:
>
>
>
>    <appender name="FILE" class="org.apache.log4j.RollingFileAppender">
>
>        <param name="maxFileSize" value="200MB" />
>
>        <param name="maxBackupIndex" value="20" />
>
>        <param name="File" value="${LOGNAME}" />
>
>        <param name="Append" value="false"/>
>
>        <layout class="org.apache.log4j.PatternLayout">
>
>            <param name="ConversionPattern"
>
>                value="%d{MM-dd HH:mm:ss.SSS} %5p %c{1} - %m%n" />
>
>        </layout>
>
>    </appender>
>
>
>
> It works fine, except that the maxBackupIndex appears to top out at
13, even
> though we have 20 specified. Are we doing something wrong or is 13 a
hard
> coded maximum for this field?


12 is a hardcoded limit because this requires renames of all backup
files which is expensive
.

-- 
Dale King

Re: Maximum backup index for RollingFileAppender

[Dale King <da...@gmail.com>]

On Wed, Jul 16, 2008 at 4:33 PM, Peter Steele <ps...@maxiscale.com> wrote:
> We use a RollingFileAppender defined as follows:
>
>
>
>    <appender name="FILE" class="org.apache.log4j.RollingFileAppender">
>
>        <param name="maxFileSize" value="200MB" />
>
>        <param name="maxBackupIndex" value="20" />
>
>        <param name="File" value="${LOGNAME}" />
>
>        <param name="Append" value="false"/>
>
>        <layout class="org.apache.log4j.PatternLayout">
>
>            <param name="ConversionPattern"
>
>                value="%d{MM-dd HH:mm:ss.SSS} %5p %c{1} - %m%n" />
>
>        </layout>
>
>    </appender>
>
>
>
> It works fine, except that the maxBackupIndex appears to top out at 13, even
> though we have 20 specified. Are we doing something wrong or is 13 a hard
> coded maximum for this field?


12 is a hardcoded limit because this requires renames of all backup
files which is expensive
.

-- 
Dale King