logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-435) Feature request: auto-delete older log files
Date Mon, 16 Nov 2015 15:15:11 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15006731#comment-15006731
] 

Remko Popma edited comment on LOG4J2-435 at 11/16/15 3:14 PM:
--------------------------------------------------------------

Robert, thank you for a lot of thoughtful feedback! Let me go over your points one by one.

*ISO8601 Duration*
I started out supporting years and months but threw that version out and reverted to a Java
8-like Duration design without years or months. The problem is that different months are different
length. So all of a sudden the starting point of the Duration becomes important. Supporting
months/years also means the implementation needs to remember the format; just tracking the
number of seconds is not enough. This would be significantly more work for hardly any gain:
I suspect most users want to clean up daily, perhaps every 7 days or maybe every 30, 60 or
90 days but probably not more infrequent, so larger units are not that useful.

About the format: if users want to specify the full ISO8601 notation they can. "P3dT12h" is
interpreted correctly. However, in addition to the full format I also want to support the
simple format because the resulting values like "30d" are much easier for users.

*Logical Grouping*
You are correct that the Delete may be configured to target different files than those created
by the rollover. I do not think this is a problem. My intention was that the grouping expresses
the _timing_ of the action rather than the target files. So when nested in a DefaultRolloverStrategy,
Delete would be triggered by a rollover, whereas when Delete is nested in a Schedule element
(something that Ralph is working on), then it would be triggered by the scheduler.

I agree with your earlier (May 11) comment that the RollingFile filePattern attribute (lumping
together the static base path and the dynamic part of the path) makes things difficult. I
recently raised LOG4J2-1198 to separate all rollover concerns into components that can be
explicitly configured. (Still very early stage, not very concrete yet, but feedback welcome
at any time.)

*Total File Size/Total File Count/Ordering*
Thanks for raising this! I had not considered these use cases. I agree that ordering becomes
important here and I had not considered that until now. I need to think about this but I would
like to support this.

About lastModified time: the {{java.nio.file}} API supports _custom_ file systems which may
not support lastModified time, but for "real" file systems I think we can rely on this being
supported and use this for ordering. That said, a file list is an interesting idea. Are you
proposing that users specify this list in configuration? Could you give a simple example of
what such a configuration would look like?


was (Author: remkop@yahoo.com):
Robert, thank you for a lot of thoughtful feedback! Let me go over your points one by one.

*ISO8601 Duration*
I started out supporting years and months but threw that version out and reverted to a Java
8-like Duration design without years or months. The problem is that different months are different
length. So all of a sudden the starting point of the Duration becomes important. Supporting
months/years also means the implementation needs to remember the format; just tracking the
number of seconds is not enough. This would be significantly more work for hardly any gain:
I suspect most users want to clean up daily, perhaps every 7 days or maybe every 30 days but
probably not more infrequent, so larger units are not that useful.

About the format: if users want to specify the full ISO8601 notation they can. "P3dT12h" is
interpreted correctly. However, in addition I also want to support the simpler "30d" format
because it is shorter and IMO more intuitive for users.

*Logical Grouping*
You are correct that the Delete may be configured to target different files than those created
by the rollover. I do not think this is a problem. My intention was that the grouping expresses
the _timing_ of the action rather than the target files. So when nested in a DefaultRolloverStrategy,
Delete would be triggered by a rollover, whereas when Delete is nested in a Schedule element
(something that Ralph is working on), then it would be triggered by the scheduler.

*Total File Size/Total File Count/Ordering*
Thanks for raising this! I had not considered these use cases. I agree that ordering becomes
important here and I had not considered that until now. I need to think about this but I would
like to support this.

About lastModified time: the {{java.nio.file}} API supports _custom_ file systems which may
not support lastModified time, but for "real" file systems I think we can rely on this being
supported and use this for ordering. That said, a file list is an interesting idea. Are you
proposing that users specify this list in configuration? Could you give a simple example of
what such a configuration would look like?

> 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message