[
https://issues.apache.org/jira/browse/LOG4J2-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17159471#comment-17159471
]
ASF subversion and git services commented on LOG4J2-2837:
---------------------------------------------------------
Commit 31340441e844383efe640e051a3d747a3ef9cd00 in logging-log4j2's branch
refs/heads/release-2.x from Carter Kozak
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=3134044 ]
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
> 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)
