[
https://issues.apache.org/jira/browse/LOG4J2-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187587#comment-15187587
]
Keld Ølykke commented on LOG4J2-1315:
-------------------------------------
Thanks.
Yes. It seems you are right. I just checked up on other frameworks. Log4J2
seems to be following industry standards.
It is kind of strange to me that the lifecycle of Logger objects cannot be
controlled by me.
With composition/inheritance patterns it seems so obvious to integrate object
and Logger lifecycle.
Btw. I am not the only with different expectations:
http://bugs.java.com/view_bug.do?bug_id=4811930 .
Anyways, I will survive now. Keep up the good work.
Cheers,
Keld Ølykke
> 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
