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: ------>8 snip, snip public static void remove() Each thread that created a diagnostic context by calling org.apache.log4j.NDC.push should call this method before exiting. Otherwise, the memory used by the thread cannot be reclaimed by the VM. 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 org.apache.log4j.NDC.remove before exiting a thread. However, you must call remove sometime. If you never call it, then your application is sure to run out of memory. ------>8 snip, snip A quick grep through all of the jboss code yields not a single call to NDC.remove(). According to the javadoc, then, "[my] application is sure to run out of memory". Is this intentional? If so, is it something that people developing JBoss applications are supposed to call? That seems unlikely. If it's _not_ intentional, should we insert a call to NDC.remove() somewhere into JBoss? I'm pretty sure we're pooling threads, so perhaps a call to NDC.remove() should be placed wherever it is that we're returning the thread to the pool. I'm happy to make the fix and commit it if someone can: (1) Tell me that I'm indeed correct and we _do_ need this call. (2) Suggest to me a good place to put it. Thanks in advance. ++jeff ------------------------------------------------------- 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
