[
https://issues.apache.org/jira/browse/LOG4J2-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159475#comment-17159475
]
ASF subversion and git services commented on LOG4J2-2837:
---------------------------------------------------------
Commit ef2820454109c770818d398689500e58866f9502 in logging-log4j2's branch
refs/heads/master from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=ef28204 ]
LOG4J2-2837: Disruptor and JUL no longer recursively start the
AsyncLoggerDisruptor
Previously logging initialization would result in an AsyncLoggerContext
initializing an AsyncLoggerDisruptor, which would access a logger from
JUL, starting the process again. This change avoids recursive calls with
a state check.
> Fully asynchronous logging results in two disruptors being created
> ------------------------------------------------------------------
>
> Key: LOG4J2-2837
> URL: https://issues.apache.org/jira/browse/LOG4J2-2837
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.13.2
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
> Fix For: 2.14.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While looking into a hang (unsure if it's related) I found that there were
> two "Log4j2-TF-AsyncLogger[context]-*" threads running.
> We end up re-initializing the logger internally when a Disruptor instance is
> created because it also requests a logger. It doesn't appear as though this
> results in an incorrect background thread ID, but the intermediate thread is
> leaked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
