[
https://issues.apache.org/jira/browse/LOG4J2-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Faisal Khan Thayub Khan updated LOG4J2-3274:
--------------------------------------------
Description:
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]}}
was:
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]}}
> 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
> Priority: Major
>
> 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)
