[
https://issues.apache.org/jira/browse/LOG4J2-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055817#comment-16055817
]
Lucio Farinosi edited comment on LOG4J2-1946 at 6/20/17 2:12 PM:
-----------------------------------------------------------------
I meant log4j 1.2 performed by default the descendingPurge and I don't have
enough background on this project to get why the default behaviour has been
changed.
>From a user perspective descendingPurge is behaving well as it is giving
>guarantee to keep the number of historic files (20 in our case), even if in
>some particular situations the indexes cannot be in strict sequence, as we
>both noticed.
By the contrary the ascendingPurge is failing because a broken sequence, for
whatever reason, makes the whole rollover strategy looping on one file
(test.log.20 in our case).
You mentioned the assumption that this is the only process deleting files from
the log dir: I believe this is not a good assumption as the framework is not
locking any file (which is a good thing for sure) and so it cannot control the
consistency of the sequence.
Looking at the code, the renaming should happen whenever the maximun index is
exceeding the number of file required (20 in our case). I attached a version of
the ascendingPurge method fixed in the sense (Fixed_ascendingPurge.java). Does
it make more sense?
was (Author: lucio.farinosi):
I meant log4j 1.2 performed by default the descendingPurge and I don't have
enough background on this project to get why the default behaviour has been
changed.
>From a user perspective descendingPurge is behaving well as it is giving
>guarantee to keep the number of historic files (20 in our case), even if in
>some particular situation the indexes cannot be in strict sequence, as we both
>noticed.
By the contrary the ascendingPurge is failing bacause a broken sequence, for
whatever reason, makes the whole rollover strategy looping on one file
(test.log.20 in our case).
You mentioned the assumption that this is the only process deleting files from
the log dir: I believe this is not a good assumption as the framework is not
locking any file (which is a good think) and so it cannot control the
consistency of the sequence.
Looking at the code, the renaming should happen whenever the maximun index is
exceeding the number of file required (20 in our case). I attached a version of
the ascendingPurge method fixed in the sense (Fixed_ascendingPurge.java). Does
it make more sense?
> 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: Fixed_ascendingPurge.java, log4j_issue.zip,
> log4j_trace.log, 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)
