[
https://issues.apache.org/jira/browse/LOG4J2-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423338#comment-16423338
]
Remko Popma commented on LOG4J2-2299:
-------------------------------------
In principle when AsyncLoggerContextSelector is selected, all loggers are
async, so having a distinction between "AsyncLogger" and "Logger" in the
configuration no longer makes sense. Parsing AsyncLoggerConfigs as standard
LoggerConfig when global async mode is enabled should be okay.
That said, it would be better if we could identify and fix the underlying cause
of the problem. Do the AsyncLogger and the AsyncLoggerConfig share the same
data structure? If the application thread hands over the same mutable/reusable
object to both the AsyncLogger background thread and the AsyncLoggerConfig
background thread, then this will cause problems...
> Using "asyncLogger" with AsyncLoggerContextSelector loses some event data
> -------------------------------------------------------------------------
>
> Key: LOG4J2-2299
> URL: https://issues.apache.org/jira/browse/LOG4J2-2299
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.11.0
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
>
> Using mixed style "asyncLogger" definitions when AsyncLoggerContextSelector
> is selected and reusable messages are enabled causes parameterized message
> data to be lost (Guessing we memento the message handing it off between
> disruptors).
> Proposal:
> Would it be objectionable to parse AsyncLoggerConfigs as standard
> LoggerConfig when global async mode is enabled?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
