logging-log4j-dev mailing list archives

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

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


Mime
View raw message