[
https://issues.apache.org/jira/browse/LOG4J2-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16149100#comment-16149100
]
Joseph Smith commented on LOG4J2-1480:
--------------------------------------
I've updated to 2.8.2 and am programmatically creating CronTriggeringPolicy's
without this error. I believe this is now fixed.
> CronTriggeringPolicy timing / file deletion issue
> -------------------------------------------------
>
> Key: LOG4J2-1480
> URL: https://issues.apache.org/jira/browse/LOG4J2-1480
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.6.2
> Environment: 2013 macbook pro running OSX El Capitan. Log4j2 is
> running as a module dependency to a bigger Vertx server project.
> Reporter: matthew beckham
>
> Most of this issue is outlined in this stack overflow post:
> http://stackoverflow.com/questions/38514101/log4j2-default-rollover-strategy-deleting-new-log-files
> This details my attempt to use the CronTriggeringPolicy to rollover a log
> file. My longterm goal was to have it roll over every 15 minutes, but used 1
> minutes intervals for testing (I did also try with 3 and 5 minute intervals
> with the same outcome).
> The gist of the issue is that after the first triggering of the cron
> triggering policy (which happens at the correct time), the rollover mechanism
> will disregard the cron schedule in place and attempt to rollover every
> second. In addition to this, the log file that is created from a rollover can
> be deleted immediately after it is created. The log file appears to not get
> deleted if there is a iterator argument (%i) in the file name though.
> I don't know if these are two separate issues, or if the file deletion is a
> side effect of the cron scheduling getting messed up.
> For now I have switched to using TimeBasedTriggeringPolicy and that appears
> to be working correctly at the moment.
> Logs and sample configuration code can be found in the linked stack overflow
> post.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
