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

Remko Popma commented on LOG4J2-1334:
-------------------------------------

Changes needed to accomplish this seem fairly straightforward:
* add class ReusableLogEvent where all LogEvent fields are mutable
* add class ReusableLogEventFactory that returns a ThreadLocal ReusableLogEvent

How to install the ReusableLogEventFactory?
* system property "Log4jLogEventFactory"  to change the default factory
* call LoggerConfig.setLogEventFactory on all logger configs

I suspect this is where most of the complexity will be to handle the case where 
synchronous and asynchronous loggers are combined in configuration. In that 
case we cannot put the ReusableLogEvent in the ring buffer since it will be 
modified. The ring buffer would have to be populated with mutable events. Need 
to think about this more.

> Add support for GC-free synchronous logging
> -------------------------------------------
>
>                 Key: LOG4J2-1334
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1334
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 2.5
>            Reporter: Remko Popma
>
> Until now I kept the scope of the garbage-free logging epic LOG4J2-1270 
> limited to asynchronous logging with all loggers asynchronous. This seemed a 
> natural thing to do since async loggers already have pre-allocated all 
> LogEvent instances.
> Now that LOG4J2-1270 is nearing completion it looks as if the only thing that 
> is required to allow synchronous logging to be garbage-free is a reusable 
> LogEvent implementation, stored in a ThreadLocal. This ticket is to analyse  
> and track the work for this option.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to