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
