Keld Ølykke created LOG4J2-1315:
-----------------------------------
Summary: 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
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]
