[
https://issues.apache.org/jira/browse/LOG4J2-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739082#comment-13739082
]
Remko Popma commented on LOG4J2-336:
------------------------------------
I was finally able to track this down to an unbalanced number of calls to
LoggerConfig#startFilter and #stopFilter. In o.a.l.l.c.c.BaseConfiguration, the
#stop() method explicitly calls the #stopFilter() method on the root logger,
but there is no equivalent call to root#startFilter in the
BaseConfiguration#start() method.
This means that the reference count (used to determine when to shut down or
create new Disruptor instances) is incorrect when the configuration contains a
{{<asyncRoot>}} element.
Proposed solution:
{code}
// o.a.l.l.c.c.BaseConfiguration
public void start() {
setup();
doConfigure();
for (final LoggerConfig logger : loggers.values()) {
logger.startFilter();
}
for (final Appender appender : appenders.values()) {
appender.start();
}
root.startFilter(); // add this line
startFilter();
}
{code}
Note that the #startFilter and #stopFilter methods may be called twice for the
root logger. Not ideal, but better than stopping twice for every start. Based
on current usage I don't see any problems. FYI, currently AsyncLoggerConfig is
the only LoggerConfig that overrides the default #startFilter and #stopFilter
implementation.
> AsyncLogger.log fail with NullPointerException after double reconfigure
> -----------------------------------------------------------------------
>
> Key: LOG4J2-336
> URL: https://issues.apache.org/jira/browse/LOG4J2-336
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-beta8
> Environment: LUbuntu 13.04, OpenJDK 7
> Reporter: Andre Bogus
>
> Using reconfigure() to select log files at runtime.
> After the second reconfigure, the next log fails with a NullPointerException
> in {{org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper:253}}
> It appears that the disruptor has been nulled and not been brought back up by
> the second {{reconfigure()}}.
> Trying to get a minimal test case I came up with the following log4j2.xml:
> {code}
> <?xml version="1.0" encoding="UTF-8" ?>
> <configuration status="debug">
> <appenders>
> <Console name="console" target="SYSTEM_OUT">
> <PatternLayout pattern="%d\{ABSOLUTE\} %6p %c %x - %m%n"/>
> </Console>
> </appenders>
> <loggers>
> <asyncroot level="WARN">
> <appender-ref ref="console" />
> </asyncroot>
> </loggers>
> </configuration>
> {code}
> The following Java class did NOT bring up the error, instead it threw a
> different exception (stack trace below):
> {code}
> import org.apache.logging.log4j.LogManager;
> import org.apache.logging.log4j.Logger;
> import org.apache.logging.log4j.core.LoggerContext;
> public class Log4jAsyncReconfTest {
> private static final Logger log =
> LogManager.getLogger(Log4jAsyncReconfTest.class);
> public static void main(String[] args) throws InterruptedException {
> System.out.println("test");
> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
> ctx.reconfigure();
> ctx.reconfigure();
> log.warn("Danger!");
> }
> }
> {code}
> ----
> throws:
> java.util.concurrent.RejectedExecutionException: Task
> com.lmax.disruptor.BatchEventProcessor@7ea4461e rejected from
> java.util.concurrent.ThreadPoolExecutor@52f79c86[Terminated, pool size = 0,
> active threads = 0, queued tasks = 0, completed tasks = 1]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
> at
> java.util.concurrent.Executors$DelegatedExecutorService.execute(Executors.java:628)
> at
> com.lmax.disruptor.dsl.EventProcessorInfo.start(EventProcessorInfo.java:77)
> at com.lmax.disruptor.dsl.Disruptor.start(Disruptor.java:263)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerConfigHelper.initDisruptor(AsyncLoggerConfigHelper.java:119)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
