You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Christian Vent (JIRA)" <ji...@apache.org> on 2017/09/01 07:25:01 UTC
[jira] [Commented] (LOG4J2-1961) Reconfigure breaks
DirectWriteRolloverStrategy
[ https://issues.apache.org/jira/browse/LOG4J2-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150163#comment-16150163 ]
Christian Vent commented on LOG4J2-1961:
----------------------------------------
Sure, I'm using MacOS Sierra (10.12.x).
{noformat}
Java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
{noformat}
> Reconfigure breaks DirectWriteRolloverStrategy
> ----------------------------------------------
>
> Key: LOG4J2-1961
> URL: https://issues.apache.org/jira/browse/LOG4J2-1961
> Project: Log4j 2
> Issue Type: Bug
> Components: Plugins
> Affects Versions: 2.8
> Reporter: Christian Vent
> Fix For: 2.9.0
>
> Attachments: DirectWriteRolloverStrategy.patch
>
>
> A reconfigure breaks {{DirectWriteRolloverStrategy}} which leads to the errors similar to that one:
> {noformat}
> 2017-06-30 10:45:56,010 Log4j2-TF-4-Scheduled-3 ERROR Log4j2 ConfigurationScheduler caught error running command java.lang.NullPointerException: activeFileName
> at java.util.Objects.requireNonNull(Objects.java:228)
> at org.apache.logging.log4j.core.appender.rolling.RolloverDescriptionImpl.<init>(RolloverDescriptionImpl.java:60)
> at org.apache.logging.log4j.core.appender.rolling.DirectWriteRolloverStrategy.rollover(DirectWriteRolloverStrategy.java:220)
> at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:388)
> at org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:304)
> at org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.rollover(CronTriggeringPolicy.java:153)
> at org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy.access$100(CronTriggeringPolicy.java:43)
> at org.apache.logging.log4j.core.appender.rolling.CronTriggeringPolicy$CronTrigger.run(CronTriggeringPolicy.java:176)
> at org.apache.logging.log4j.core.config.ConfigurationScheduler$CronRunnable.run(ConfigurationScheduler.java:230)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Durring the rollover the system is using the field {{currentFileName}}, which might be null after an reconfigure:
> {code:java|title=org.apache.logging.log4j.core.appender.rolling.DirectWriteRolloverStrategy#rollover}
> ...
> Action compressAction = null;
> final String sourceName = currentFileName;
> String compressedName = sourceName;
> ...
> {code}
> Instead of that I'd propose to use {{getCurrentFileName()}} directly, to access the field. Doing so the field would be initialised again, if necessary.
> {code:java|title=org.apache.logging.log4j.core.appender.rolling.DirectWriteRolloverStrategy#rollover}
> ...
> Action compressAction = null;
> final String sourceName = getCurrentFileName(manager);
> String compressedName = sourceName;
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)