You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2016/03/22 09:26:25 UTC
[jira] [Comment Edited] (LOG4J2-1324) Async Logger - Consumer
thread dying - new thread unable to start
[ https://issues.apache.org/jira/browse/LOG4J2-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205641#comment-15205641 ]
Remko Popma edited comment on LOG4J2-1324 at 3/22/16 8:26 AM:
--------------------------------------------------------------
Thanks for the environment update and config. Can you also add what operating system (and version) you are on?
Looking at the Thread Dump, the AsyncLoggerConfig-1 thread is not actually dead, it is waiting for a notification before it tries to take another event from the ring buffer. Previously someone reported a similar issue (LOG4J2-1221, external issue https://github.com/LMAX-Exchange/disruptor/issues/138) when running on Solaris. Because of this we are making com.lmax.disruptor.TimeoutBlockingWaitStrategy the default in Log4j-2.6.
I'm trying to think of a workaround that would help you between now and the 2.6 release, but TimeoutBlockingWaitStrategy does not have a default constructor, so it will take a bit of hacking to install it. (Specifying the fully qualified class name of this class for system property {{AsyncLoggerConfig.WaitStrategy}} will not work.)
About the AsyncLoggerConfig-2 thread, looking at the Thread Dump it is waiting for data to become available in a LinkedBlockingQueue. I don't know what this thread is. The thread name suggests it is a log4j thread, but as far as I know we don't use LinkedBlockingQueue in log4j... Did you create a ThreadPool with log4j's DaemonThreadFactory?
was (Author: remkop@yahoo.com):
Thanks for the environment update and config. Can you also add what operating system (and version) you are on?
Looking at the Thread Dump, the AsyncLoggerConfig-1 thread is not actually dead, it is waiting for a notification before it tries to take another event from the ring buffer. Previously someone reported a similar issue (LOG4J2-1221) when running on Solaris. Because of this we are making com.lmax.disruptor.TimeoutBlockingWaitStrategy the default in Log4j-2.6.
I'm trying to think of a way to install TimeoutBlockingWaitStrategy in the current version 2.5, but this strategy does not have a default constructor, so it will take a bit of hacking to install it. (Specifying the fully qualified class name of this class for system property {{AsyncLoggerConfig.WaitStrategy}} will not work.)
About the AsyncLoggerConfig-2 thread, looking at the Thread Dump it is waiting for data to become available in a LinkedBlockingQueue. I don't know what this thread is. The thread name suggests it is a log4j thread, but as far as I know we don't use LinkedBlockingQueue in log4j... Did you create a ThreadPool with log4j's DaemonThreadFactory?
> Async Logger - Consumer thread dying - new thread unable to start
> -----------------------------------------------------------------
>
> Key: LOG4J2-1324
> URL: https://issues.apache.org/jira/browse/LOG4J2-1324
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2
> Environment: LOG4J CORE Release Version 2.2
> Disruptor Bundle-Version 3.3.2
> ORACLE jdk1.8.0_45
> Reporter: Ron Gonzalez
> Attachments: 2016-03-18_17-44-06.jpg, BatchEventProcessor.png, log4j2_config.xml
>
>
> We are seeing a situation where the consumer thread
> "AsyncLoggerConfig-1" is apparently dying.
> We do see a new consumer thread trying to start up, but it is blocked
> waiting for a lock, so no logging is happening.
> Is this a defect in log4j?
> Is the original consumer thread dying due to perhaps an unhandled exception ?
> Is that original consumer thread not terminating gracefully and
> releasing the locked object so the new consumer thread can start?
> Please see attached screenshot. Top of screen is normal
> asyncloggerconfig thread (consumer).
> Bottom is thread trace when logging stops, we no longer see an
> "asyncloggerconfig-1" thread, instead a new thread is trying to start
> but never does "asyncloggerconfig-2".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org