Remko Popma commented on LOG4J2-2301:

Started to look at this. Interesting idea.

So the idea is basically that previously, we had a single call to, let's say 
{{callAppenders(LogEvent)}} (actual method may be different), and that has now 
been split into two: first call the synchronous, then the async downstream 
components. Would it be possible to rearrange the code so that this intention 
becomes very clear? Something like (pseudo-code):

// before

// after 
// (add comment with quick summary of why we're doing this and link to 
callAppenders(logEvent, LogPredicate.SYNCRONOUS_ONLY);
callAppenders(logEvent, LogPredicate.ASYNCRONOUS_ONLY);

Detail: Can we pass a {{LoggingPredicate.ALWAYS}} constant instead of {{null}} 
so client code can just call {{predicate.allow(LoggerConfig)}} without needing 
to check for null? 

> 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