[
https://issues.apache.org/jira/browse/LOG4J2-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15187461#comment-15187461
]
Keld Ølykke commented on LOG4J2-1315:
-------------------------------------
Hi Ralph,
Yes, I have just done so as a workaround.
I am not generating a logger name for each event. A business object has
lifetime and it will log 0 or many messages in its lifetime.
It is not up to me to impose an api change on you guys - that might be lots of
work - I don't have the overview.
However, it is a problem that the api lets the developer introduce memory leaks
without knowing so.
It didn't occur to me that the number of loggers would become a problem. I
simply introduced a logger field in our business entity and had the id field as
a handy string at construction time.
Maybe a warning in the getLogger documentation is enough?
Kind Regards,
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: [email protected]
For additional commands, e-mail: [email protected]
