[jira] [Comment Edited] (LOG4J2-1858) Memory issues with ParameterizedMessage

["Remko Popma (JIRA)" <ji...@apache.org>]

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

Remko Popma edited comment on LOG4J2-1858 at 4/14/17 4:47 PM:
--------------------------------------------------------------

Thanks for spotting that min/max mistake!

Trimming happens [in a few places|https://github.com/apache/logging-log4j2/search?utf8=%E2%9C%93&q=trimToSize&type=]. 

FYI, ReusableParameterizedMessage also has a StringBuilder field, but this is rarely used because in garbage-free mode, the {{formatTo(StringBuilder)}} method is used instead of {{getFormattedMessage}}. The StringBuilder passed to formatTo is owned by the caller (MutableLogEvent or RingBufferLogEvent). The owner does the trimming.


was (Author: remkop@yahoo.com):
Thanks for spotting that min/max mistake!

Trimming happens [in a few places|https://github.com/apache/logging-log4j2/search?utf8=%E2%9C%93&q=trimToSize&type=]. 

FYI, ReusableParameterizedMessage also has a StringBuilder field, but this is rarely used because in garbage-free mode, the {{formatTo(StringBuilder)}} method is used instead of {{getFormattedMessage}}.

> Memory issues with ParameterizedMessage
> ---------------------------------------
>
>                 Key: LOG4J2-1858
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1858
>             Project: Log4j 2
>          Issue Type: Bug
>            Reporter: Adrien Grand
>            Assignee: Remko Popma
>
> ParameterizedMessage keeps track of a ThreadLocal<StringBuilder> in order to save object creations. However, the reused string builders can only grow over time, which may end up causing memory issues after some large messages have been logged. This is especially true if the application uses a fixed thread pool since the string builders cannot be collected at all.
> One way to address that issue would be to drop the string builder if it grows too large, but I have concerns that this could cause garbage collection issues if this happens too often (since those string builders might not die young). So maybe this class should go back to create the StringBuilder on demand and make sure it always dies young?
> For the record, this problem seems to have been introduced in LOG4J2-1271 / https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blobdiff;f=log4j-api/src/main/java/org/apache/logging/log4j/message/ParameterizedMessage.java;h=d315c1345b5fb72c8d88f5e1aa177011c7376fb9;hp=334e19ba7c188e8ac862863830cf17dca7b7007c;hb=dca586c;hpb=047565e8928b0c9893c25ee92ffdf48dbcd6965c.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)