[ 
https://issues.apache.org/jira/browse/LOG4J2-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205484#comment-15205484
 ] 

Ron Gonzalez edited comment on LOG4J2-1324 at 3/22/16 12:58 AM:
----------------------------------------------------------------

it looks like the batcheventprocessor is defaulting to the 
com.lmax.disruptorFatalExceptionHandler, we don't have an exception handler 
defined otherwise.  

# I wonder whether the new AsyncLoggerConfig-2 thread is failing to start due 
to the default of "blocking strategy" lock, rather than wait strategy.  
# Does the consumer hold open the file descriptor to the log file, or are there 
certain circumstances where the OS file descriptor to the log file itself on 
disk is released back to the OS and a new file descriptor is acquired?


was (Author: rong):
it looks like the batcheventprocessor is defaulting to the 
com.lmax.disruptorFatalExceptionHandler, we don't have an exception handler 
defined otherwise.  I wonder whether the new AsyncLoggerConfig-2 thread is 
failing to start due to the default of "blocking strategy" lock, rather than 
wait strategy.

> Async Appender - 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
>            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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to