[
https://issues.apache.org/jira/browse/LOG4J2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15364522#comment-15364522
]
Ralph Goers commented on LOG4J2-1457:
-------------------------------------
The workaround for this would be to modify your pattern layout configuration to
not use the extended stack trace and just use %ex. This will mean you won't get
the extra information on what jar file and version are being used but it should
be faster and will not try to load the classes.
In looking at the thread dump I can't tell what thread got the exception that
is being logged or what classes are involved. The only clue I can find is that
there are several runnable threads doing:
{code}
java.lang.Thread.State: RUNNABLE
at
x.core.services.x.GemFirexMapEntryFactory.createValue(GemFirexMapEntryFactory.java:22)
at com.x.x.persistence.map.MapHandler.toValue(MapHandler.java:118)
at
com.x.x.persistence.map.cache.CachedStructure.put(CachedStructure.java:148)
at
com.x.x.persistence.map.cache.CachedMapPersister.persist(CachedMapPersister.java:110)
at
com.x.x.persistence.map.ManagedPersister.persist(ManagedPersister.java:121)
at
com.x.x.dispatcher.GuaranteedDispatcher.dispatch(GuaranteedDispatcher.java:114)
at
com.x.x.prosumer.SubjectProducerDelegate.send(SubjectProducerDelegate.java:220)
at
com.x.x.prosumer.SubjectProducerDelegate.send(SubjectProducerDelegate.java:204)
at
com.x.x.prosumer.SubjectProducerDelegate.send(SubjectProducerDelegate.java:184)
{code}
Since I don't have access to that code I can't really say what might be going
on. Do you have the ability to see what the getValue method might be doing?
One possible way to try to fix this would be to not delegate to an async logger
if the logging call includes an exception. However, I am not sure why that
wouldn't just then block in the thread where the exception is thrown - unless
the cause of this is that the async logger threads are using a different class
loader than the application that threw the exception. All the classes involved
in the exception should have already been loaded by the class loader - unless
there is something wrong with the class and the exception being thrown has to
do with loading it.
> 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: 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
