[ 
https://issues.apache.org/jira/browse/LOG4J2-2301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440369#comment-16440369
 ] 

Carter Kozak commented on LOG4J2-2301:
--------------------------------------

That is correct. Good call on the predicate!

To clarify, the old approach could end up enqueuing N events on the 
AsyncLoggerConfig disruptor, where N is the number of AsyncLoggerConfig 
elements between the event source and root (or where additivity is disabled, or 
the event is filtered). This approach enqueues at most one event to the 
disruptor ringbuffer.


I've updated the PR with an attempt to clean up the implementation, thanks for 
your feedback! It's a bit tricky to split the paths apart because we have to 
maintain thread state as we invoke through potentially both AsyncLoggerConfig 
and LoggerConfig instances chained together, and only the first encountered 
AsyncLoggerConfig enqueues events to the ringbuffer.

> gc-free mixed async loging loses parameter values after the first appender
> --------------------------------------------------------------------------
>
>                 Key: LOG4J2-2301
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2301
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.11.0
>            Reporter: Carter Kozak
>            Assignee: Carter Kozak
>            Priority: Major
>
> When gc-free logging is used with mixed synchronous/asynchronous loggers, 
> parameter values are replaced with "null" after the first AsyncLoggerConfig.
> The message format is still present, as well as the parameter count, however 
> all values are nulls.
> It appears that Log4jEventWrapperHandler.onEvent invokes 
> MutableLogEvent.clear, which nulls out the parameter array.
> I have constructed a failing test (which I need to clean up and deduplicate 
> some code from the fix for LOG4J2-2299):
> https://github.com/cakofony/logging-log4j2/commit/b9c03f5c6881bfe778f8e2d75d046ce6e021c4f1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to