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)