[
https://issues.apache.org/jira/browse/LOG4J2-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13892821#comment-13892821
]
Remko Popma commented on LOG4J2-493:
------------------------------------
They are not related: LOG4J2-511 is about the underlying appender (e.g.
FileAppender) being stopped while the AsyncAppender still has log events in its
queue and the async thread is still passing these events to the FileAppender.
This issue (LOG4J2-493) has to do with deploy-undeploy-deploy-undeploy use
cases in web apps.
I did not consider this use case in enough depth when designing the Async
Loggers. The implementation for making all loggers async uses a static
initializer block to set up and start the Disruptor. (AsyncLogger line 116-)
This works fine if the class is unloaded when the web app is undeployed (when
the log4j-core jar is in WEB-INF/lib), but causes issues if the class is _not_
unloaded when the web app is undeployed (when the log4j-core jar is in the
application server's shared lib directory).
Note that mixing Async Loggers with synchronous Loggers does not have this
problem as the implementation is different. {{AsyncLoggerConfigHelper}} is
tracking the ref count and only shuts down the Disruptor if the ref count is
zero. It also allows for re-creating a new Disruptor if the ref count goes up
again.
Ideally we should do something similar in {{AsyncLogger}}. But until then, the
workaround is to put the log4j-core jar in WEB-INF/lib...
> NPE in AsyncLogger.shutdown
> ---------------------------
>
> Key: LOG4J2-493
> URL: https://issues.apache.org/jira/browse/LOG4J2-493
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0-beta9
> Environment: tomcat 7.0.42
> Reporter: Kireet Reddy
>
> When redeploying my application in tomcat multiple times, I get an exception:
> Exception in thread "Thread-29" java.lang.NullPointerException
> at
> org.apache.logging.log4j.core.async.AsyncLogger.stop(AsyncLogger.java:249)
> at
> org.apache.logging.log4j.core.async.AsyncLoggerContext.stop(AsyncLoggerContext.java:56)
> at
> org.apache.logging.log4j.core.LoggerContext$ShutdownThread.run(LoggerContext.java:437)
> This seems to be due to the fact that some initialization code happens in the
> class initializer but is undone in the stop() method which is called during
> webapp undeployment. This causes issues because in this case the log4j jar is
> loaded by the shared classloader ($catalina.home/lib) rather than the webapp
> classloader. This means the AsyncLogger class is not re-created during webapp
> deployment.
> I am using this structure because I have many 3rd party libraries and want to
> keep redeployments lightweight.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
