FYI: our production server went down this weekend due to excessive amounts of threads. The client XmlBlaster side collapsed when it reached 850 threads. Why are not the threads closed down and reclaimed manually, or is it something I do not understand here?
Very ugly! A client side thread leak.
As soon as the Global is recycled all resources (like threads) are freed. If not to depend on the garbage collector you can explicitly call
glob.shutdown();
when a client connection is finished.
Guessing your environment:
- Linux - JDK 1.4 - Using Jacorb (CORBA) to communicate ??
Marcel
PS: What about the tests below?
PPS: We could make a glob.shutdown() in con.disconnect()
but this needs to investigate side effects first.
//Peter On Sun, 2003-09-28 at 17:23, Marcel Ruff wrote:
Hi Peter,
fact is that on client side the threads grows suddenly after a time of no thread leak, it happens on you machine but not on mine.
It seems that the client side Global (one for each connection) is suddenly not gc'd anymore. This Global holds the threads which we see in your log output.
I have added the lines
glob.shutdown(); glob = null;
to your xmlBlaster/testsuite/src/java/org/xmlBlaster/test/memoryleak/TestThreadLeak.java (in cvs). It shouldn't be necessary as this cleanup is done in finalize() as well when the glob is gc'd.
Could you please rerun your tests and report again?
thanks
Marcel
PS: Even if the problem has disappeared in your environment (what i believe) it is a bit strange as it would look like a JVM bug.
-- http://www.xmlBlaster.org
-- http://www.xmlBlaster.org