[
https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035748#comment-15035748
]
Robert Schaft commented on LOG4J2-435:
--------------------------------------
Ok, let's continue the iteration.
You misread the 3rd case. I wanted to delete files beyond the 10th file
(because they are uninteresting) OR beyond 100mb (because my guaranteed disk
space for these kind of files is limited).
To your example: It would be very confusing if children of one element are
combined using OR, while children of other elements are combined using AND -
but both don't contain AND or OR.
Here is a first Gedankenexperiment:
Each {{<Delete>}} contains exactly one selector element (the As and Bs).
There are also two combining selectors: {{<And>}} and {{<Or>}}.
The 3rd case might be formulated as:
{code:xml}
<Delete baseDir="${sys:base}">
<And>
<FileName glob="debug-*.log">
<LastModified age="1d">
<Or>
<AccumulatedFileCount exceeds="10" />
<AccumulatedFileSize exceeds="100 mb">
</Or>
</And>
</Delete>
{code}
Although this would be from my point of view a very readable solution, it has
one major problem:
Because of the sequence problem of xml elements that Ralph mentioned, the
combining selectors are not allowed to be shortcut operators. This means that
always all elements below the combining selectors are evaluated - even other
combining selectors and accumulators.
But if accumulators are always evalulated, accumulating over a subset is not
possible.
Therefore the sequence problem of xml elements prohibits this solution.
Second Gedankenexperiment:
An IF-THEN-ELSE could be seen as shortcut operator:
- The IF-THEN part represents a shortcut AND (the THEN part is not executed if
the IF part evaluates to false)
- the IF-ELSE part is a shortcut OR operator (the ELSE part is not executed if
the IF part evaluates to TRUE)
How would the configuration look if we strictly orient at that
{code:xml}
<Delete baseDir="${sys:base}">
<If>
<FileName glob="debug-*.log" />
<Then>
<If>
<LastModified age="1d" />
<Then>
<If>
<AccumulatedFileCount exceeds="10" />
<Then>
<DeleteIt />
</Then>
<Else>
<If>
<AccumulatedFileSize exceeds="100 mb">
<Then>
<DeleteIt />
</Then>
</If>
</Else>
</If>
</Then>
</If>
</Then>
</If>
</Delete>
{code}
This is mathematically complete with shortcut operator. But there are three
problems:
# nesting is ugly. I got nearly lost closing all the {{If}}s and {{Then}}s.
# We have two {{<DeleteIt>}} elements. This is an indicator that something is
strange.
# There is an outer {{<Delete>}} and an inner {{<DeleteIt}} element. Another
indicator for strangeness :)
Let's try to avoid some nesting levels by using the non-shortcut {{<And>}} and
{{<Or>}} operation from above:
{code:xml}
<Delete baseDir="${sys:base}">
<If>
<And>
<FileName glob="debug-*.log" />
<LastModified age="1d" />
</And>
<Then>
<If>
<Or>
<AccumulatedFileCount exceeds="10" />
<AccumulatedFileSize exceeds="100 mb" />
</Or>
<Then>
<DeleteIt />
</Then>
</If>
</Then>
</If>
</Delete>
{code}
Looks nicer, doesn't it? But all three mentioned problems remain. Only the
nesting problem is not that problematic any more.
If we try to eliminate further elements, we come again quickly to xml sequence
problems.
In the current form, each {{<Delete>}} contains exactly one {{Action}}. There
are two {{Action}}s: {{<If>}} and {{<DeleteIt>}}. Each {{<If>}} contains
exactly one {{Selector}}, at most one {{<Then>}} and at most one {{<Else>}}.
The {{<Then>}} and {{<Else>}} contain exactly one {{Action}}. The sequence is
not a problem. The following configuration would have the exact same result:
{code:xml}
<Delete baseDir="${sys:base}">
<If>
<Then>
<If>
<Then>
<DeleteIt />
</Then>
<Or>
<AccumulatedFileSize exceeds="100 mb" />
<AccumulatedFileCount exceeds="10" />
</Or>
</If>
</Then>
<And>
<LastModified age="1d" />
<FileName glob="debug-*.log" />
</And>
</If>
</Delete>
{code}
Now if you make any level implicit (e.g. {{<If>}} or {{<DeleteIt>}}), you end
up with a confusing configuration. Try it.
Solution: perhaps in my next post.
> 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
