[
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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
