使用 DefaultRolloverStrategy 删除 log4j2 日志不起作用

Question

I'm using log4j2 version 2.13.3 and I'm trying to delete old logs on application startup. I've tried various examples and they didn't even trigger my DefaultRolloverStrategy . I implemented a configuration like this:

<properties>
    <property name="filePattern">${date:yyyy-MM-dd}</property>
    <Property name="baseDirectory">logs</Property>
</properties>

<Appenders>
<!-- ... -->
<RollingFile name="RollingFile" append="true" fileName="${baseDirectory}/${filePattern}.log"
         filePattern="${baseDirectory}/%d{yyyy-MM-dd}.log">
<PatternLayout>
    <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
</PatternLayout>
<Policies>
    <OnStartupTriggeringPolicy/>
</Policies>
<DefaultRolloverStrategy>
    <Delete basePath="${baseDirectory}" maxDepth="1">
        <IfFileName glob="*.log"/>
        <IfLastModified age="10d"/>
    </Delete>
</DefaultRolloverStrategy>
</RollingFile>
</Appenders>

<OnStartupTriggeringPolicy/> actually triggers my DefaultRolloverStrategy on startup but then the eligable files turn out to be empty:

As a consequence no logs are deleted but I'm fairly confident that my configuration is correct. Is there anything I'm missing or why does the getEligibleFiles() method abort if my log file pattern doesn't match their strange PATTERN_COUNTER constant?

Answer 1

The scenario getEilligleFiles is accounting for is to determine which files to delete according to the rules specified on the DefaultRolloverStrategy. That strategy only deletes files within the timeframe of the current time pattern. For example, if you rollover every hour it will only purge files within the current hour. That is actually, the reason the delete action came to be - most people want to delete files in the whole directory or set of directories, not limited to the current "window".

The "strange PATTERN_COUNTER constant" is there to check for counters expressed as %[0]n[n...]i in the file name. That pattern causes the counter to be a fixed length with leading zeros. You aren't using the SizeBasedTriggeringPolicy and so don't have the %i in your file pattern, so it won't match on that.

In other words, this code isn't doing anything because it doesn't apply to your configuration.

When looking at DefaultRolloverStrategy you can see that its builder accepts custom Actions. These are added during configuration and you should be able to see them if you have -Dlog4j2.debug enabled or have status=DEBUG set on the Configuration element in your Log4j2 config file. You will also notice they are added to the RolloverDescription at the end of the rollover method. This is passed back to RollingFileManager which does

           if (success && descriptor.getAsynchronous() != null) {
                LOGGER.debug("RollingFileManager executing async {}", descriptor.getAsynchronous());
                asyncExecutor.execute(new AsyncAction(descriptor.getAsynchronous(), this));
                releaseRequired = false;
            }

near the end of the rollover method. This will cause the Delete action will be kicked off as an asynchronous task at the end of every rollover.

Again, enabling -Dlog4j2.debug or setting status=Debug should allow you to see these called.