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

Reply via email to