Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.13.3
-
None
-
None
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
I'm not confident the two are related.
What do you think?