Carl Smotricz created LOG4J2-3432:
-------------------------------------
Summary: RollingFileAppender fails after 100 backup cycles if
filePattern contains "%04i" .
Key: LOG4J2-3432
URL: https://issues.apache.org/jira/browse/LOG4J2-3432
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.17.1
Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
* java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
* 301873 Mar 9 07:53 log4j-api-2.17.1.jar
1790452 Mar 9 07:53 log4j-core-2.17.1.jar
Reporter: Carl Smotricz
Attachments: Main.java, log4j2.xml, runit.sh
If a {{%i}} formatter in a filePattern includes a width specifier, e.g. "%4i"
or "%04i", file renaming fails after a certain fixed number of cycles. After
that, successive backups are renamed to the maximum cycle number and overwrite
previous files of that same cycle number, regardless of min and max settings on
the appender. Here are some failure modes I've found by testing:
* if {{filePattern}} contains {{{}%06i{}}}, cycling breaks after 100.
* if {{filePattern}} contains {{{}%006i{}}}, it breaks after 100 also.
* if {{filePattern}} contains {{{}%6i{}}}, it breaks after 10.
* if {{filePattern}} contains {{%06i}} and
{{{}DefaultRolloverStrategy.min{}}}=10000, {{{}max{}}}=99999, it breaks after
just 1.
Now, the doc doesn't mention the %i spec supporting width and leading zero
modifiers in the manner of printf() or String.format() . Yet, those variations
(which I think other users will also be tempted to try) work - until they
don't. So apparently width and padding on that spec are implemented but buggy.
The doc for RollingRandomAccessFileAppender explicitly recommends these format
modifiers:
{quote}... and/or a %i which represents an integer counter. The integer counter
allows specifying a padding, like %3i for space-padding the counter to 3 digits
or (usually more useful) %03i for zero-padding the counter to 3 digits.
{quote}
...but I haven't verified that the problem occurs with that appender as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
