[jira] [Commented] (LOG4J2-2269) Memory leaking of replacement parameters in case of enableThreadlocals=true

["Mike Wilkinson (JIRA)" <ji...@apache.org>]

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

Mike Wilkinson commented on LOG4J2-2269:
----------------------------------------

Hello, I am not sure if the issue I am seeing is related to this fix or not but I am seeing a behavior change from log4j2 2.11.0 to 2.11.1 which is that the MutableLogeEvent.getLoggerName() method returns the name of the Logger that logged the event in 2.11.0 but in 2.11.1 the call returns null.

> Memory leaking of replacement parameters in case of enableThreadlocals=true
> ---------------------------------------------------------------------------
>
>                 Key: LOG4J2-2269
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2269
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>            Reporter: Dmitry Konstantinov
>            Assignee: Remko Popma
>            Priority: Major
>             Fix For: 3.0.0
>
>         Attachments: heap_dump_references.png, heap_dump_threadLocals_false.hprof.zip, heap_dump_threadLocals_true.hprof.zip, test_to_reproduce.zip
>
>
> Use case:
> 1) I have a thread pool with quite large number of threads (around 100)
> 2) Threads from the pool sometimes process some heavy objects. Threads are not actively writing into logs (so, a thread may process a task and does not log any message).
> 3) As a part of processing for some objects in some non-frequently used branch a thread logged a message with heavy replacement parameters (parameterized log message is used).
> In this case such heavy replacement parameters are not garbage collected until another message will not written within the same thread because thread-local ReusableParameterizedMessage and MutableLogEvent objects keep references to the replacement parameters.
> Is it possible to cleanup such references when a message is released (for example as a part of org.apache.logging.log4j.message.ReusableMessageFactory#release and org.apache.logging.log4j.core.impl.ReusableLogEventFactory#release) to avoid such kind of leaks?



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