[
https://issues.apache.org/jira/browse/LOG4J2-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Heiko Schwanke updated LOG4J2-2766:
-----------------------------------
Description:
If a RollingRandomAccessFile is updated with a new TimeBasedTriggeringPolicy
during runtime, the new value is not updated until the original interval is
reached once.
E.g. if logging is initialized with the rule to rotate every day and is later
rerconfigured to rotate every hour, then you have to wait until the next day in
order to get hourly rotated files.
This has to do with the ordering in the Update-Method of
RollingRandomAccessFileManager. Before the new PatternProcessor is created the
RollingRandomAccessFileManager initializes his TriggeringPolicy from the former
PatternProcessor.
org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager:
{code:java}
public void updateData(final Object data) {
final FactoryData factoryData = (FactoryData) data;
setRolloverStrategy(factoryData.getRolloverStrategy());
setTriggeringPolicy(factoryData.getTriggeringPolicy()); // ->
TimeBasedTriggeringPolicy.initialize will use old PatternProcessor
setPatternProcessor(new PatternProcessor(factoryData.getPattern(),
getPatternProcessor()));
}
{code}
org.apache.logging.log4j.core.appender.rolling.TimeBasedTriggeringPolicy:
{code:java}
public void initialize(final RollingFileManager aManager) {
this.manager = aManager;
long current = aManager.getFileTime();
if (current == 0) {
current = System.currentTimeMillis();
} // LOG4J2-531: call getNextTime twice to force initialization of both
prevFileTime and nextFileTime
aManager.getPatternProcessor().getNextTime(current, interval, modulate);
aManager.getPatternProcessor().setTimeBased(true);
nextRolloverMillis = ThreadLocalRandom.current().nextLong(0, 1 +
maxRandomDelayMillis)
+ aManager.getPatternProcessor().getNextTime(current, interval,
modulate); // -> time comes from the old PatternProcessor (see above:
RollingRandomAccessFileManager.updateData)
}
{code}
See also the attached simple testcase.
was:
If a RollingRandomAccessFile is updated with a new TimeBasedTriggeringPolicy
during runtime, the new value is not updated until the original interval is
reached once.
E.g. if logging is initialized with the rule to rotate every day and is later
rerconfigured to rotate every hour, then you have to wait until the next day in
order to get hourly rotated files.
This has to do with the ordering in the Update-Method of
RollingRandomAccessFileManager. Before the new PatternProcessor is created the
RollingRandomAccessFileManager initializes his TriggeringPolicy from the former
PatternProcessor.
org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager:
{code:java}
public void updateData(final Object data) {
final FactoryData factoryData = (FactoryData) data;
setRolloverStrategy(factoryData.getRolloverStrategy());
setTriggeringPolicy(factoryData.getTriggeringPolicy()); // ->
TimeBasedTriggeringPolicy.initialize will use old PatternProcessor
setPatternProcessor(new PatternProcessor(factoryData.getPattern(),
getPatternProcessor()));
}
{code}
org.apache.logging.log4j.core.appender.rolling.TimeBasedTriggeringPolicy:
{code:java}
public void initialize(final RollingFileManager aManager) {
this.manager = aManager;
long current = aManager.getFileTime();
if (current == 0) {
current = System.currentTimeMillis();
} // LOG4J2-531: call getNextTime twice to force initialization of both
prevFileTime and nextFileTime
aManager.getPatternProcessor().getNextTime(current, interval, modulate);
aManager.getPatternProcessor().setTimeBased(true); nextRolloverMillis =
ThreadLocalRandom.current().nextLong(0, 1 + maxRandomDelayMillis)
+ aManager.getPatternProcessor().getNextTime(current, interval,
modulate); // -> time comes from the old PatternProcessor (see above:
RollingRandomAccessFileManager.updateData)
}
{code}
See also the attached simple testcase.
> TimeBasedTriggeringPolicy of RollingRandomAccessFile is not instantly updated
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-2766
> URL: https://issues.apache.org/jira/browse/LOG4J2-2766
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders, Configurators
> Affects Versions: 2.13.0
> Reporter: Heiko Schwanke
> Priority: Minor
> Attachments: testcase.zip
>
>
> If a RollingRandomAccessFile is updated with a new TimeBasedTriggeringPolicy
> during runtime, the new value is not updated until the original interval is
> reached once.
>
> E.g. if logging is initialized with the rule to rotate every day and is later
> rerconfigured to rotate every hour, then you have to wait until the next day
> in order to get hourly rotated files.
> This has to do with the ordering in the Update-Method of
> RollingRandomAccessFileManager. Before the new PatternProcessor is created
> the RollingRandomAccessFileManager initializes his TriggeringPolicy from the
> former PatternProcessor.
> org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager:
> {code:java}
> public void updateData(final Object data) {
> final FactoryData factoryData = (FactoryData) data;
> setRolloverStrategy(factoryData.getRolloverStrategy());
> setTriggeringPolicy(factoryData.getTriggeringPolicy()); // ->
> TimeBasedTriggeringPolicy.initialize will use old PatternProcessor
> setPatternProcessor(new PatternProcessor(factoryData.getPattern(),
> getPatternProcessor()));
> }
> {code}
> org.apache.logging.log4j.core.appender.rolling.TimeBasedTriggeringPolicy:
> {code:java}
> public void initialize(final RollingFileManager aManager) {
> this.manager = aManager;
> long current = aManager.getFileTime();
> if (current == 0) {
> current = System.currentTimeMillis();
> } // LOG4J2-531: call getNextTime twice to force initialization of both
> prevFileTime and nextFileTime
> aManager.getPatternProcessor().getNextTime(current, interval, modulate);
> aManager.getPatternProcessor().setTimeBased(true);
> nextRolloverMillis = ThreadLocalRandom.current().nextLong(0, 1 +
> maxRandomDelayMillis)
> + aManager.getPatternProcessor().getNextTime(current, interval,
> modulate); // -> time comes from the old PatternProcessor (see above:
> RollingRandomAccessFileManager.updateData)
> }
> {code}
> See also the attached simple testcase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
