[jira] [Assigned] (LOG4J2-2938) Consider logging all events from background threads synchronously

["Carter Kozak (Jira)" <ji...@apache.org>]

     [ 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)