[
https://issues.apache.org/jira/browse/LOG4J2-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keld Ølykke updated LOG4J2-1315:
--------------------------------
Attachment: screenshot-2.png
> How to clean up retained heap memory (synchronous)
> ---------------------------------------------------
>
> Key: LOG4J2-1315
> URL: https://issues.apache.org/jira/browse/LOG4J2-1315
> Project: Log4j 2
> Issue Type: Question
> Components: Core
> Affects Versions: 2.2
> Environment: JDK 7, multithreaded application
> Reporter: Keld Ølykke
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> Hi,
> In our application every business object has a unique name. We use this name
> as logger name in LogManager.getLogger. This is pretty nice, since we can
> trace object-logging across threads.
> While playing around with Eclipse Memory Analyzer it detected leak #1 to be
> in LoggerContext:
> ---
> One instance of "org.apache.logging.log4j.core.LoggerContext" loaded by
> "sun.misc.Launcher$AppClassLoader @ 0x70001f6d8" occupies 5,970,696 (40.97%)
> bytes. The memory is accumulated in one instance of
> "java.util.concurrent.ConcurrentHashMap$Segment[]" loaded by "<system class
> loader>".
> Keywords
> sun.misc.Launcher$AppClassLoader @ 0x70001f6d8
> org.apache.logging.log4j.core.LoggerContext
> java.util.concurrent.ConcurrentHashMap$Segment[]
> ---
> Now 40% is a big deal and I fear that it is growing. We do not use async
> logging, so I don't think this is related to a ring-buffer.
> If I use Class-name instead as logger name, no log4j2 leaks turn up.
> Even though our business objects are discarded (object lifecycle control is
> in place), I don't know what to call in log4j2 to cleanup the retained memory.
> I guess I am missing LogManager.destroyLogger or similar.
> Any ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
