[
https://issues.apache.org/jira/browse/LOG4J2-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187375#comment-15187375
]
Ralph Goers commented on LOG4J2-1315:
-------------------------------------
I'm very tempted to close this as won't fix.
The main purpose of a Logger's name is to match it to a configuration element
to determine what should happen to the log event. If you are generating unique
Logger names for each event I have no idea how you are matching them to the
appropriate configuration.
The business object name is really a separate attribute of the log event. In
Log4j 2 it would make more sense for you to create a special MessageFactory
that includes your Object name in the Message and use that MessageFactory on
the getLogger() call. Then every message logged would include the name but as
part of the Message, not as the Logger.
> 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]
