The queue being full means that the application is logging faster than the underlying appenders can handle. It’s not necessarily an indication that there’s a problem with the async loggers that sit in the middle.
Things I’ve seen in the past that may cause the queue filling up: * using a custom Appender that has a performance issue * the console Appender is 50x slower than logging to a file * logging to a database If one thread is still runnable then there’s no deadlock; I would look into slow appenders first. Logging in the toString method used to cause an actual deadlock but that was fixed in 2.7; I believe we now log a warning and (if memory serves correctly) we bypass the ringbuffer and log directly to the underlying appenders; I could be wrong about the details. What does your configuration look like? Any appenders or filters that could be a performance bottleneck? (Shameless plug) Every java main() method deserves http://picocli.info > On Feb 21, 2020, at 4:28, Mark Butler <markhenrybut...@gmail.com> wrote: > > Hello team > > I am using Apache Log4j2 2.13.0 with LMax Disrupter 3.4.2 > > I encountering problems were occasionally an instance will go into > deadlock. All threads are deadlocking here: > > org.apache.logging.log4j.core.async.AsyncLoggerDisruptor.enqueueLogMessageWhenQueueFull(RingBufferLogEventTranslator) > AsyncLoggerDisruptor.java:229 > org.apache.logging.log4j.spi.AbstractLogger.warn(Message) > AbstractLogger.java:2629 > > except one thread that seems to be runnable here > > Log4j2-TF-1-AsyncLogger[AsyncContext@1de0aca6]-1 Runnable Thread ID: 22 > > org.apache.logging.log4j.core.async.RingBufferLogEventHandler.onEvent(Object, > long, boolean) RingBufferLogEventHandler.java:29 > com.lmax.disruptor.BatchEventProcessor.processEvents() > BatchEventProcessor.java:168 > com.lmax.disruptor.BatchEventProcessor.run() BatchEventProcessor.java:125 > java.lang.Thread.run() Thread.java:834 > > I can see similar deadlock issues reported in the past > > https://issues.apache.org/jira/browse/LOG4J2-1518 > > where toString was also logging. I can't see evidence of that in my thread > dump or my code but it's possible a dependency somewhere is doing this. > > I wonder if this recent change has caused a regression > > https://github.com/apache/logging-log4j2/commit/72e777708b50b5cf6240f70eafcc4b08797a0047#diff-f77d8b534ecffa0241d582d43424f4a5 > > as the deadlock I am seeing is happening here? > > https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/async/AsyncLoggerDisruptor.java#L229 > > Any suggestions how to resolve? Thank you! > > Mark --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
