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