[
https://issues.apache.org/jira/browse/LOG4J2-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292541#comment-17292541
]
Ralph Goers commented on LOG4J2-2981:
-------------------------------------
After running the existing unit test I am realizing your analysis isn't exactly
correct. It seems that RollingFileManager.getFileManager() is called from
RollingFileAppender before anything is initialized. the getManager() method
calls the static getManager method in OutputStreamManager which delegates to
AbstractManager's getManager method (this is standard practice in all the
Appender Managers). It then calls RollingFileManager's createManager method.
The createManager method checks if the configuration included a fileName. If it
does and the append attribute is true then it sets size to the file's size.
Otherwise the size ends up zero here. This makes sense because if append is
false you are indicating that you want to overwrite the file and if no filename
attribute is provided the name of the file isn't known yet.
So to encounter the case you are observing you must either be using the
DirectWriteRolloverStrategy or have set append to false. I wouldn't consider it
to be a bug if append is false since that directly conflicts with the idea of
rolling on startup. So that only leaves the DirectWrite case and I must assume
that is how you have your appender configured.
I have created a test that confirms the problem when direct write is used and
modified the code so that test now passes.
> OnStartupTriggeringPolicy only rolls over when minsize = 0
> ----------------------------------------------------------
>
> Key: LOG4J2-2981
> URL: https://issues.apache.org/jira/browse/LOG4J2-2981
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.14.0
> Reporter: Samuel Martin
> Assignee: Ralph Goers
> Priority: Minor
> Labels: Policy, RollingFileAppender
>
> I am trying to use a {{RollingFileAppender}} with a
> {{CompositeTriggeringPolicy}} that includes a {{OnStartupTriggeringPolicy}}
> which is deemed to rollover the log when the JVM is (re-)started.
> However, I have noted that the files only roll over on startup when I specify
> "minsize = 0" on the log4j2.xml configuration file. If I put any other value
> or leave the minsize unspecified (i.e. rely on its default value minsize =
> 1), the appender proceeds writing to the previously existing file.
> I have run the debugger and traced down the bug according as follows.
> All the logic in {{OnStartupTriggeringPolicy.initialize()}} is conditioned
> upon the size of the rolling file being larger than {{minSize}}
> {code:java}
> public void initialize(final RollingFileManager manager) {
> if (manager.getFileTime() < JVM_START_TIME && manager.getFileSize()
> >= minSize) {
> ...
> }
> }
> {code}
> However, {{manager.getFileSize()}} always returns 0, thus the body of that if
> is never entered (... unless {{minSize == 0}}). In fact, this call to
> {{OnStartupTriggeringPolicy.initialize()}} is invoked indeed from
> {{RollingFileManager.initialize()}} *before* any value has been assigned to
> {{size}}
> {code:java}
> public void initialize() {
> if (!initialized) {
> LOGGER.debug("Initializing triggering policy {}",
> triggeringPolicy);
> initialized = true;
> triggeringPolicy.initialize(this);
> if (triggeringPolicy instanceof LifeCycle) {
> ((LifeCycle) triggeringPolicy).start();
> }
> if (directWrite) {
> // LOG4J2-2485: Initialize size from the most recently
> written file.
> File file = new File(getFileName());
> if (file.exists()) {
> size = file.length();
> } else {
> ((DirectFileRolloverStrategy)
> rolloverStrategy).clearCurrentFileName();
> }
> }
> }
> }
> {code}
> Thus, within {{OnStartupTriggeringPolicy.initialize()}},
> {{manager.getFileSize()}} always evaluates to {{0}}, and the only way that
> the file is rolled over at startup is that {{minSize}} has been configured as
> {{0}}.
> As a side consequence, this may also affect SizeBaseTriggerinPolicy if a
> rollover is needed by coincidence during startup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
