SizeRollingPolicy fails to retrieve eligible files

[snicoll]

Description

Apologizes for the lack of details but @ppkarwasz mentioned they could reproduce the problem on their end.

I am configuring a SizeBasedTriggeringPolicy on a Spring Boot application and rolling fails as follows:

2025-12-12T14:23:34.834545Z scheduling-1 ERROR An exception occurred processing Appender File
java.lang.IndexOutOfBoundsException: No group 1
	at java.base/java.util.regex.Matcher.checkGroup(Matcher.java:1845)
	at java.base/java.util.regex.Matcher.group(Matcher.java:686)
	at org.apache.logging.log4j.core.appender.rolling.AbstractRolloverStrategy.getEligibleFiles(AbstractRolloverStrategy.java:144)
	at org.apache.logging.log4j.core.appender.rolling.AbstractRolloverStrategy.getEligibleFiles(AbstractRolloverStrategy.java:93)
	at org.apache.logging.log4j.core.appender.rolling.AbstractRolloverStrategy.getEligibleFiles(AbstractRolloverStrategy.java:85)
	at org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.purgeAscending(DefaultRolloverStrategy.java:447)
	at org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.purge(DefaultRolloverStrategy.java:431)
	at org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.rollover(DefaultRolloverStrategy.java:571)
	at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:619)
	at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:507)
	at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:418)
	at org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:336)
	at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:160)
	at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:133)
	at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:124)
	at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:88)
	at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:711)
	at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:669)
	at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:645)
	at org.apache.logging.log4j.core.config.LoggerConfig.logParent(LoggerConfig.java:702)
	at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:671)
	at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:645)
	at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:589)
	at org.apache.logging.log4j.core.config.DefaultReliabilityStrategy.log(DefaultReliabilityStrategy.java:73)
	at org.apache.logging.log4j.core.Logger.log(Logger.java:187)
	at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2970)
	at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2922)
	at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2904)
	at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:2653)
	at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:2393)
	at org.apache.logging.slf4j.Log4jLogger.debug(Log4jLogger.java:113)

When this happens logs to file stop.

Configuration

Log4J 2.25.2, MacOS, JDK 25

[ppkarwasz]

The problem occurs if filePattern contains something that matches .*%(?<ZEROPAD>0)?(?<PADDING>\d+)?i.*, but it doesn't actually contain any valid %i pattern.

Patterns such as %%i match the regex without being a true %i, which causes the method to fail.

[vy]

I suggest either documenting, or "fixing" this. What "the fix" will be, is still an open question.

[snicoll]

@vy I think I am confused.

With 2.24.3, a filePattern of ${sys:LOG_FILE}.%d{yyyy-MM-dd}.%i.gz generates something like this:

myapp.log
myapp.log.2025-12-15.1.gz
myapp.log.2025-12-15.2.gz
myapp.log.2025-12-15.3.gz
myapp.log.2025-12-15.4.gz

With 2.25.2 it generates something like:

myapp.log
myapp.log.test.2025-12-16.%i.61025CET

(throws the exception above and then stops logging to file).

How can it be a documentation fix? What's wrong with this pattern and why does it work with Log4j 2.24?

[ppkarwasz]

Hi @snicoll,

Could you provide a complete configuration file and possibly a reproducer? The issue appears to be some sort of concurrency/reentrancy issue in the date formatter: 2025-12-16.%i.61025CET seems like a partially overwritten version of a timestamp.

We had such an issue in #3792, but we fixed it in version 2.25.1.

[snicoll]

Could you provide a complete configuration file and possibly a reproducer?

Unfortunately this only happens with the code in the PR you and I are working on. I've tried to reproduce on main with 2.25.2 and I couldn't. The PR is actually providing support for rolling policy so it might miss something important, I have no idea. If you're ok to build from source, you can reproduce by cloning snicoll@pr/47260 and running this main method. You need to wait a bit for the main log file to hit 100KB.