[
https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029333#comment-15029333
]
Remko Popma commented on LOG4J2-435:
------------------------------------
Robert, *all* conditions must be true before a file is deleted, so files that
do not match the glob will not be deleted.
However, you raise a good point: order does make a difference. You may end up
keeping files you wanted to delete. Fortunately the wrong order will not result
in deleting too much.
If you match the file name first, only matching files are counted. _This is
probably what you want._ If there are 6 test-\*.log files, the most recent 5
are kept. The my-\*.log files are also kept.
{code}
<!-- delete only test-*.logs, keep the 5 most recent ones -->
<Delete baseDir="${sys:base}">
<IfFileName glob="test-*.log" />
<IfAccumulatedCount exceeds="5" />
</Delete>
// equivalent pseudocode:
int count = 0;
for (Path path : mostRecentPathsFirst) {
if (path.matches("test-*.log") && ++count > 5) { // count not incremented
if file name does not match
Files.delete(path);
}
}
{code}
If you count first, the first 5 most recent files are ignored, and after that
only files matching the pattern are deleted. _This may not give you what you
want._ If the my-\*.log files are more recent, they "consume" the count of
files to keep and _all_ test-\*.log files are deleted.
{code}
<!-- keep the 5 most recent files, after that delete the remaining test-*.log
files -->
<Delete baseDir="${sys:base}">
<IfAccumulatedCount exceeds="5" />
<IfFileName glob="test-*.log" />
</Delete>
// equivalent pseudocode:
int count = 0;
for (Path path : mostRecentPathsFirst) {
if (++count > 5 && path.matches("test-*.log")) {
Files.delete(path);
}
}
{code}
I don't see any way to "fix" this; this is simply how the accumulating filters
work. In that sense they are a risky tool and users need to understand how they
work. I will include the above examples in the documentation.
I am also considering a "testOnly" attribute: if users configure {{<Delete
baseDir="..." testOnly="true">}} files will not actually be deleted but instead
a message will be printed to the status logger. Users can use this to do a dry
run to test if their configuration works as expected.
> Feature request: auto-delete older log files
> ---------------------------------------------
>
> Key: LOG4J2-435
> URL: https://issues.apache.org/jira/browse/LOG4J2-435
> Project: Log4j 2
> Issue Type: Improvement
> Reporter: Arkin Yetis
> Assignee: Remko Popma
> Labels: Rollover
> Fix For: 2.5
>
> Attachments: LimitingRolloverStrategy.java, SizeParser.java
>
>
> Original description:
> {quote}
> DefaultRolloverStrategy max attribute only applies if you have a %i in the
> file pattern. This request is to enhance DefaultRolloverStrategy or another
> appropriate component to allow a max number of files limit to apply across
> days/months/years when a filePattern includes a date pattern.
> {quote}
> ----
> One of the most requested features is to add the ability to Log4j to "clean
> up" older log files. This usually means deleting these files, although it
> could also mean moving them to a different location, or some combination of
> these.
> Users have different requirements for selecting the files to clean up. A
> common request is the ability to keep the last X number of log files. This
> works well if rollover is only date based but may give undesired results with
> size based rollover.
> Another factor to consider is that the directory containing the log files may
> contain the log files for multiple appenders, or even files unrelated to
> logging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
