You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Steffen Offermann (JIRA)" <ji...@apache.org> on 2016/04/08 08:08:25 UTC
[jira] [Comment Edited] (LOG4J2-1350) Circuit Breaker for log
system to avoid DOS by recursion
[ https://issues.apache.org/jira/browse/LOG4J2-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231692#comment-15231692 ]
Steffen Offermann edited comment on LOG4J2-1350 at 4/8/16 6:07 AM:
-------------------------------------------------------------------
Thanks for your responses, [~rkpkuipers] & [~jvz]!
The {{AsyncEventRouter}} _may_ be an approach to solve the problem, but I can only tell after trying it. In our case it's not just that _some_ log messages get lost - once the ring buffer is full, no logging _at all_ will ever happen again, i.e. the log event consumer(s) is/are apparently in a deadlock situation.
@[~jvz]:
A burst filter does not look like a solution in this situation.
was (Author: steffeno):
Thanks for your responses, [~rkpkuipers]] & [~jvz]!
The {{AsyncEventRouter}} _may_ be an approach to solve the problem, but I can only tell after trying it. In our case it's not just that _some_ log messages get lost - once the ring buffer is full, no logging _at all_ will ever happen again, i.e. the log event consumer(s) is/are apparently in a deadlock situation.
@[~jvz]:
A burst filter does not look like a solution in this situation.
> Circuit Breaker for log system to avoid DOS by recursion
> --------------------------------------------------------
>
> Key: LOG4J2-1350
> URL: https://issues.apache.org/jira/browse/LOG4J2-1350
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.5
> Reporter: Steffen Offermann
>
> We have encountered the following situation: A method in an application thread was recursively calling itself again and again, until the inevitable {{StackOverflowException}} occurred. Other application threads worked fine, but since we use asynchronous logging, the Log4j ring buffer ran full because of the thread that was running amok. As a consequence none of the other threads could issue any log messages any more.
> In production systems we MUST be able to see log messages, otherwise we have hardly a means to tell when something goes wrong and to discover problems like this.
> So my suggestion would be to add a circuit breaker pattern to the Log4j core system (unless there already is one that I'm not aware of), that would track the frequency of log events per thread and open once a dangerous threshold has been reached or exceeded. That way other threads would still be able to send log events once the ring buffer is free again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org