[
https://issues.apache.org/jira/browse/LOG4J2-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carter Kozak reassigned LOG4J2-2938:
------------------------------------
Assignee: Carter Kozak
> 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
> Assignee: Carter Kozak
> Priority: Major
>
> 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)
