[
https://issues.apache.org/jira/browse/LOG4J2-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054297#comment-16054297
]
Ralph Goers edited comment on LOG4J2-1946 at 6/19/17 4:42 PM:
--------------------------------------------------------------
I guess this isn't too surprising. The code is looking at the files in the
directory and less than 20 files are present so it isn't going to delete the
oldest one. It then runs through the renames and probably is getting an error
when it tries to rename a file. To be sure though we need the debug log My
guess is that since item 20 wasn't deleted it is having a problem trying to
rename file 19 to 20. Please change status=INFO to status=DEBUG = in your
configuration and provide the logs.
was (Author: [email protected]):
I guess this isn't too surprising. The code is looking at the files in the
directory and less than 20 files are present so it isn't going to delete the
oldest one. It then runs through the renames and probably is getting an error
when it tries to rename a file. To be sure though we need the debug log. Please
change status=INFO to status=DEBUG = in your configuration and provide the logs.
> DefaultRolloverStrategy is failing if some log file is deleted from the
> current sequence
> ----------------------------------------------------------------------------------------
>
> Key: LOG4J2-1946
> URL: https://issues.apache.org/jira/browse/LOG4J2-1946
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.8.2
> Reporter: Lucio Farinosi
> Attachments: log4j_issue.zip, screenshot-1.png
>
>
> A wrong behaviour in rollover strategy has been reported to me today which is
> related to a problem on the DefaultRolloverStrategy.
> The case specific settings are:
> - RollingRandomAccessFile appender
> - SizeBasedTriggeringPolicy set to 1MB
> - DefaultRolloverStrategy with max set to 20
> - filePattern without date (i.e. C:/log/test.log.%i)
> When the rollover action begins (the moment the 20th file is completed) if
> someone deletes one of more files from the current sequence (for example
> test.log.8 and/or test.log.9 or whatever) the purgeAscending method is
> failing in engaging the rollover actions in the correct way and this results
> in a rollover effect limited only to 2 files (the other files are not updated
> anymore - in a similar way already observed and fixed in
> https://issues.apache.org/jira/browse/LOG4J2-1821).
> I managed to reproduce the problem in the attached simple project, even in
> single threaded execution.
> Note that I managed to workaround the problem adding a fake fileIndex to the
> appender appender.R.strategy.fileIndex=xxxx which results in engaging the
> purgeDescending method of the same class which is working fine.
> The completed log4j2.properties file is listed below.
> status=INFO
> monitorInterval=5
> appender.R.type=RollingRandomAccessFile
> appender.R.name=R
> appender.R.fileName=C:/log/test.log
> appender.R.layout.type=PatternLayout
> appender.R.layout.pattern=%d{dd-MM-yyyy HH:mm:ss,SSS} [%mdc] %p %c{1.} [%t]
> %m %ex%n
> appender.R.filePattern=C:/log/test.log.%i
> appender.R.policies.type=Policies
> appender.R.policies.size.type=SizeBasedTriggeringPolicy
> appender.R.policies.size.size=1MB
> appender.R.strategy.type=DefaultRolloverStrategy
> appender.R.strategy.max=20
> rootLogger.level=INFO
> rootLogger.appenderRef.R.ref=R
> #added to workaround the issue
> #appender.R.strategy.fileIndex=xxxx
> Could you please check it out and/or advise accordingly?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
