Carter Kozak created LOG4J2-2938:
------------------------------------
Summary: Consider logging all events from background threads
synchronously
Key: LOG4J2-2938
URL: https://issues.apache.org/jira/browse/LOG4J2-2938
Project: Log4j 2
Issue Type: Improvement
Components: Core
Affects Versions: 2.13.3
Reporter: Carter Kozak
There's a class of issues that can occur when events are logged in the process
of logging other events. We have relatively strong handling for these cases
(especially the case where a statement causes itself to be logged recursively)
in the synchronous implementation, however the behavior works differently when
fully asynchronous logging is used.
In the worst case, fully asynchronous logging allows an event to log itself
until the queue is full, at which point recursion is detected before blocking
or logging synchronously.
We can unify the asynchronous and blocking codepaths by always logging
synchronously when events are produced on a Log4jThread. When events are
produced from the backgroudn thread, there's no reason to cause churn through
the entire queue. Synchronous events must be supported already to handle the
full-queue case.
For context, I've been thinking about this while trying to get to the root
cause of [https://github.com/LMAX-Exchange/disruptor/issues/307.] I'm not
confident the two are related.
What do you think?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
