[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Socket test with thread leak?
Peter Antman wrote:
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?
A client side thread leak.
As soon as the Global is recycled all resources (like threads)
If not to depend on the garbage collector you
can explicitly call
when a client connection is finished.
Guessing your environment:
- JDK 1.4
- Using Jacorb (CORBA) to communicate
PS: What about the tests below?
PPS: We could make a glob.shutdown() in con.disconnect()
but this needs to investigate side effects first.
On Sun, 2003-09-28 at 17:23, Marcel Ruff wrote:
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 = null;
to your xmlBlaster/testsuite/src/java/org/xmlBlaster/test/memoryleak/TestThreadLeak.java
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?
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.