Why isn't the data freed when the thread dies?
Is there a general solution to this problem?
Do we control the thread creation in these cases? Could we use a Thread
sub-class which would automatically call NDC.remove() prior to exiting
run()?
FYI, the javadoc for remove():
<snip>
<p>Each thread that created a diagnostic context by calling
{@link #push} should call this method before exiting. Otherwise,
the memory used by the <b>thread</b> cannot be reclaimed by the
VM.
<p>As this is such an important problem in heavy duty systems and
because it is difficult to always guarantee that the remove
method is called before exiting a thread, this method has been
augmented to lazily remove references to dead threads. In
practice, this means that you can be a little sloppy and
occasionally forget to call {@link #remove} before exiting a
thread. However, you must call <code>remove</code> sometime. If
you never call it, then your application is sure to run out of
memory.
</snip>
--jason
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:jboss-
> [EMAIL PROTECTED]] On Behalf Of Jeffrey Wescott
> Sent: Thursday, October 10, 2002 3:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Possible leak in JBoss due to
> org.apache.log4j.NDC usage mistake?
>
> It's also used in the LoggingInterceptor, actually, whenever
invokeHome is
> called. Perhaps that one is more problematic?
>
> ++jeff
>
>
> On Thursday 10 October 2002 02:47 pm, Scott M Stark wrote:
> > I find it hard to believe that in 3 days NDC accumulation is what
blows
> out
> > the memory. The primary usage of NDC is the service life cycle
methods.
> > Just add a remove call where the NDC is popped in the create, start,
> stop
> > and destroy methods of org.jboss.system.ServiceController and see if
> that
> > fixes the memory issue.
> >
> > xxxxxxxxxxxxxxxxxxxxxxxx
> > Scott Stark
> > Chief Technology Officer
> > JBoss Group, LLC
> > xxxxxxxxxxxxxxxxxxxxxxxx
> >
> > ----- Original Message -----
> > From: "Jeffrey Wescott" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, October 10, 2002 2:11 PM
> > Subject: [JBoss-dev] Possible leak in JBoss due to
org.apache.log4j.NDC
> > usage mistake?
> >
> >
> > Hi, all.
> >
> > For the past few days, I've been running the JBoss server (3.0.3) in
> > OptimizeIt with our application. I started this effort because our
> > application seems to stay "up and running" for only about 3 days
before
> > finally quitting when it runs out of memory.
> >
> > Within OptimizeIt, one thing that you start to notice right away is
a
> lot
> > of never-freed instances of
java.lang.ThreadLocal$ThreadLocalMap$Entry
> > objects. If you follow the reduced reference graph to its root,
you'll
> find
> > that most of these objects are contained within the static "table"
> member
> > of the org.apache.log4j.NDC class.
> >
> > I've looked through all of the JBoss code and its usage with regard
to
> the
> > NDC class, and all looks okay, with one exception. According to the
> > javadoc for org.apache.log4j.NDC:
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
