You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Faisal Khan Thayub Khan (Jira)" <ji...@apache.org> on 2021/12/22 15:10:00 UTC

[jira] [Created] (LOG4J2-3274) Log4j2 deadlock version 2.16

Faisal Khan Thayub Khan created LOG4J2-3274:
-----------------------------------------------

             Summary: Log4j2 deadlock version 2.16
                 Key: LOG4J2-3274
                 URL: https://issues.apache.org/jira/browse/LOG4J2-3274
             Project: Log4j 2
          Issue Type: Bug
            Reporter: Faisal Khan Thayub Khan


My application is a sprint boot application that uses log4j2 and runs in a Wildfly server. After the zero day attack, we upgraded to the latest log4j2 version(2.16). But after the log4j upgrade, my application stops working once in a while. And when I looked at the threaddumps, I found that there is a deadlock created by log4j. 

When analysing this issue, I came through a possible defect in log4j code. Not sure if that can result in a deadlock.

*Log4J possible bug* - As per the release notes, there was a fix to {*}Enable immediate flush on RollingFileAppender when buffered i/o is not enabled. (LOG4J2-3114){*}. But the code just does the opposite in RollingFileAppenderBuilder.

It should have been {{{}if(!bufferedIo) \{ immediateFlush = true; }{}}}. And one of my appender explicitly sets bufferedIo value to true. I know that log4j does a bufferedio by default and it is not necessary to set this flag explicitly. But unfortunately the code that I am working on is a legacy code and the configuration was working fine before the upgrade.

{{I have added my log4j configuration in here [https://stackoverflow.com/questions/70450611/log4j2-deadlock]}}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)