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

ASF subversion and git services commented on LOG4J2-2269:
---------------------------------------------------------

Commit b28496e325663f770bc0889d7f5ed2e07505851d in logging-log4j2's branch 
refs/heads/master from [~ckozak]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=b28496e ]

LOG4J2-2269: ReusableLogEventFactory.release clears MutableLogEvent

Fixes a memory leak where parameter references were held beyond
MutableLogEvent usage.


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

Reply via email to