[
https://issues.apache.org/jira/browse/LOG4J2-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187507#comment-15187507
]
Ralph Goers commented on LOG4J2-1315:
-------------------------------------
I understand you are not generating a new logger name for each event. You are
calling getLogger() with a new name for each new business object. Instead, have
the logger name match the class name and have each business object implement
the Message interface to include the Object's name as part of what is being
logged, or create a generic Message that knows how to get the object's name.
We can add a warning, but every existing logging framework works this way,
including java.util.logging, so it would seem most everyone already is aware of
this.
> 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: Server with log4j2 - 1 logger per object - class logger
> name.png, Server with log4j2 - 1 logger per object - unique logger name.png,
> 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]
