[
https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15372064#comment-15372064
]
Leon Finker commented on LOG4J2-1457:
-------------------------------------
Yes that's what I tried at first. But then this test failed:
{noformat}
Expected: a collection with size <1>
but: collection size was <0>
at
org.apache.logging.log4j.core.ExtendedLevelTest.testLevelLogging(ExtendedLevelTest.java:58).testLevelLogging:58
{noformat}
The stack trace that leads to the class load is:
{noformat}
at
org.apache.logging.log4j.core.util.Loader.initializeClass(Loader.java:242)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:210)
at
org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:231)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:496)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:249)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:239)
at
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:158)
at
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:130)
at
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:100)
at
org.apache.logging.log4j.junit.LoggerContextRule$1.evaluate(LoggerContextRule.java:92)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
{noformat}
The call is to load the plugins:
Loader.initializeClass(type.getPluginClass().getName(),
type.getPluginClass().getClassLoader());
...
Specifically this plugin for the test:
PluginType [pluginClass=class org.apache.logging.log4j.test.ExtendedLevels,
key=extendedlevel, elementName=ExtendedLevel, isObjectPrintable=false,
isDeferChildren==false, category=level]
ExtendedLevels class declares few static fields as Levels. So unless static
initializer runs for ExtendedLevels, the test will not work. The @Plugin
annotated classes are auto processed.
{noformat}
@Plugin(name="ExtendedLevel", category="Level")
public class ExtendedLevels {
public static final Level NOTE = Level.forName("NOTE", 350);
public static final Level DETAIL = Level.forName("DETAIL", 450);
}
{noformat}
> Class loader deadlock when using async logging
> ----------------------------------------------
>
> Key: LOG4J2-1457
> URL: https://issues.apache.org/jira/browse/LOG4J2-1457
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.6.1
> Environment: On CentOS 6.7 and Java 1.8.0_60.
> Reporter: Leon Finker
> Priority: Critical
> Attachments: LOG4J2-1457.patch, threaddump.txt
>
>
> We've encountered a class loading deadlock. Please review attached thread
> dump. Is it possible to have an option of pre-initializing the exception's
> thread stack on the caller's thread? It's hard to predict what libraries are
> doing in their classes' static initializers and may eventually end up logging
> and causing deadlock.
> In the attached thread dump here are the threads of interest:
> "Log4j2-AsyncLogger[AsyncContext@18b4aac2]1" #16 daemon prio=5 os_prio=0
> tid=0x00007ff870c7b000 nid=0x79f3 in Object.wait() [0x00007ff839142000]
> java.lang.Thread.State: RUNNABLE
> at java.lang.Class.forName0(Native Method)
> ...
> and
> "1A03340:Company:japan" #568 prio=5 os_prio=0 tid=0x00007ff871677000
> nid=0x725 runnable [0x00007ff74bd27000]
> ...<clinit>...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
