NDC "Memory Leak" without directly referencing it

[pr...@paypa.ch]

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  
backendComponent.
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...

Patrick

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
%x%m%n

...
log4j.appender.FILE_BUSINESS_JOURNAL.layout.ConversionPattern=%d{ISO8601}  
%-15.15t
%-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

Re: NDC "Memory Leak" without directly referencing it

[Patrick Reolon <pr...@paypa.ch>]

Thanks so far...
This may be possible, hough the heap from the coredump wasn't showing  
many EJBs there. And I've asked to get me a stacktrace from the  
coredump, to see in which context NDC was refereenced.
But I will also check our advice with EJB's being not properly  
finalized, that could be also one reason..

But may I ask: How come, that the NDC class is used though I don't  
reference it directly? In all the documentation I've found concerning  
NDC, the class is always directly refrerenced. Or is it indirectly  
used via the log-configuration?
I would be interested in knowing that.

Thanks and regards

Patrick


Am 06.11.2009 um 09:47 schrieb Michael Erskine:

> Sounds like the contextual information isn't being popped off the  
> stack - ensure your EJBs are being properly finalised and destroyed.
>
> Regards,
> Michael Erskine.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>


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

RE: NDC "Memory Leak" without directly referencing it

[Michael Erskine <mi...@ketech.com>]

Sounds like the contextual information isn't being popped off the stack - ensure your EJBs are being properly finalised and destroyed.

Regards,
Michael Erskine.

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