[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jacorb-bugs
Subject:    [jacorb-bugs] [Bug 726] Huge numbers of threads created in client
From:       bugzilla-daemon () inf ! fu-berlin ! de
Date:       2007-04-19 21:24:16
Message-ID: E1Hee6y-0003eg-00 () berners ! inf ! fu-berlin ! de
[Download RAW message or body]

http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=726





------- Additional Comments From bbtt0@comcast.net  2007-04-19 23:24 -------
We have also seen a critical memory leak related to the creation of a Timer
thread per request when pending reply timeouts are enabled.  

We are running JacORB 2.2.4 on Windows XP, using Sun JDK 1.5.0_09.  During
system testing we ran many tests with and without pending reply timeouts
enabled.  It leaked consistently whenever pending reply timeouts were enabled,
and didn't leak when they were disabled.

For example, in one test our application was making about 5 requests per second,
resulting in 5 Timer threads being created (and destroyed) per second.  All
services were running on the same box as the client, and I didn't notice any
kind of network delays.   

According to Task Manager the total number of application threads remained
steady, but the memory size ("VM Size" in Task Manager) increased at a steady
rate of 7 MB / hour in the Client VM and 20+ MB / hour in the Server VM. 
Running with JProbe showed that there was NOT a leak in the Java heap.

After patching the ORB to use a single Timer thread and a TimerTask per request,
the application no longer leaks memory when running with the Client VM.  (We are
still seeing unpredictable behavior with the Server VM - sometimes it leaks and
sometimes it doesn't - although that may be unrelated).

I don't know why the memory leak is occurring even when the total number of
threads was not increasing.  Maybe Windows can't keep up with the rapid rate of
thread creation / destruction, or perhaps it's some native leak in Hotspot that
is being exposed.  Whatever the reason, it is a critical issue, and any kind of
network delays or problems that would actually cause the timeouts to be
exercised would make it even worse (as others have reported).

It looks like the code that creates the Timer thread per request still exists in
version 2.3.0.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


[prev in list] [next in list] [prev in thread] [next in thread]