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

Remko Popma commented on LOG4J2-1858:
-------------------------------------

The way we handle this issue in other places is to trimToLength the 
StringBuilder if it exceeds some reasonable maximum. Looks like this one 
slipped through the cracks. 

You have a point that the old char[] array will likely be moved to the oldgen 
space, but we found that constructing a new StringBuilder for each message has 
significant performance impact. 

You may be aware that since version 2.6 Log4j can be configured to be garbage 
free, in which case ReusableParameterizedMessage is used instead of  
ParameterizedMessage. This is where StringBuilders are trimmed when they exceed 
some threshold. The threshold is configurable, so you can adjust if your system 
frequently logs large messages. 

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

Reply via email to