You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Remko Popma (Jira)" <ji...@apache.org> on 2020/09/30 06:53:00 UTC
[jira] [Updated] (LOG4J2-2938) Consider logging all events from
background threads synchronously
[ https://issues.apache.org/jira/browse/LOG4J2-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Remko Popma updated LOG4J2-2938:
--------------------------------
Description:
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|https://github.com/LMAX-Exchange/disruptor/issues/307.]
I'm not confident the two are related.
What do you think?
was:
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?
> 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|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)