I guess I just _assumed_ we were pooling threads. Even if we're not, and
eventually our threads _are_ dying, the point is ... there isn't a _single
call_ to NDC.remove() _anywhere_ in the JBoss code. Thus, not even the "dead
thread" memory usage will be cleaned up. If we _are_ pooling threads, then a
periodic call to NDC.remove() from outside the thread itself won't help.
BTW -- that same javadoc was in my original message. :-)
++jeff
On Thursday 10 October 2002 03:51 pm, Jason Dillon wrote:
> 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
-------------------------------------------------------
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
