logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1315) How to clean up retained heap memory (synchronous)
Date Wed, 09 Mar 2016 17:50:40 GMT

    [ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message