logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From preo...@paypa.ch
Subject NDC "Memory Leak" without directly referencing it
Date Thu, 05 Nov 2009 14:49:08 GMT
Hi all,

We have in our company a very strange memory leak we can't directly  
point at the cause.
CoreDump/Heap Analysis have showed that over time NDC is growing to a  
size of around 1GB
leading then to a jvm-failure.

We have now tried to find the cause of this NDC growing but didn't  
find any reasonable
origin because: In our code we have no single reference to NDC.
we only log via LOG.debug() & such.

My question is now:
is it possible that one of our ConversionPattern indirectly makes use  
of the NDC and thus
enriches it constantly with information we do not remove?
and genreally: how come that NDC is growing and growing when we're not  
pushing messages
into it?

For further info: The Problem appears in a backend component, which is  
called via EJB
2.0, this backend component contains the whole businesslogic, access  
to other two
components via EJB, DB-Access via EJB and Access to a message Queue.  
One construct which
could influence the NDC Problem is: we're using ThreadLocals in this  
The Problem raised since our Migration to WebSPhere61 after 2 months  
uptime of the
AppServer, under WebSphere51 we never had similar problems (uptime > 8  
10 months).
(ThreadLocal Implementation under WAS61 seems to be not cleaning up  
after threads have
been used... we had there a problem too which is now fixed...)
But I don't now if ThreadLocals are the right way...

Thx for any aclaration concerning possible indirect/implicit NDC-usage...


Here the ConversionPatterns we use:

log4j.appender.FILE.layout.ConversionPattern=%d{ISO8601} %-15.15t  
%-70.70c %-5.5p %x%m%n

log4j.appender.FILE_EIS.layout.ConversionPattern=%d{ISO8601} %-15.15t  
%-70.70c %-5.5p

%-40.40c %-5.5p %x%m%n

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message