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

["Dmitry Konstantinov (JIRA)" <ji...@apache.org>]

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

Dmitry Konstantinov commented on LOG4J2-2269:
---------------------------------------------

Please find in attach a code to reproduce the problem - [^test_to_reproduce.zip]. It is not pure Unit test, it is quite tricky to reproduce the problem in format of a usual unit test because the observable effects are side ones.

If we run the test with -Dlog4j2.enableThreadlocals=true (default) we got a result like: 
{code}
Used heap size: 101 Mb, max heap size: 245 Mb 
{code}
at the end of execution.
For  -Dlog4j2.enableThreadlocals=false the same test gives:
{code}
Used heap size: 3 Mb, max heap size: 245 Mb
{code}
Heap dumps for both cases are also attached to the ticket:  [^heap_dump_threadLocals_false.hprof.zip] ,  [^heap_dump_threadLocals_true.hprof.zip] 

In heap dump  [^heap_dump_threadLocals_true.hprof.zip]  we see that the application level heavy objects (TaskContext) are kept in memory because of log4j2 references in thread locals:
 !heap_dump_references.png! 



> 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
>         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)