Name: skT45625 Date: 05/03/2000


G:\Java Projects\SDR\camcyber\repl\common>java -version
java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

Consider a situation in which two servers are exchanging information. Server S
is the "initial" server of the pair. Server Q "registers" a new object with S
via one of S's public methods by sending a stringified object reference to S. S
converts and narrows the reference as appropriate and uses it subsequently to
send information back to Q. Q runs the standard, default Sun-supplied ORB. S
runs the following ORB extension:

package camcyber.repl.common;

public class SdrOrb extends com.sun.CORBA.iiop.ORB
{
        public void setServerPort(int port) { ORBServerPort = port; }
}

(I need this extension to control the port S uses, so Q can contact S through a
firewall)

Q must create a new ORB object each time it loses contact with S.
As a first cut at creating the new object, Q
would disconnect all server objects and call the ORB's shutdown() method with
a "false" parameter value. By checking Q's default thread group, I notice that
Q gets a new "JavaIDL Listener" thread each time it creates a new ORB. That is,
the shutdown() method does not terminate the server thread. Eventually Q eats
up all associated system resources and dies badly. I see this when I run Q by
itself, with no S to talk to (Q creates a new ORB each time it polls to see if
S is alive) or if S comes up and then goes down for an extended period.

I tried to isolate the ORB server thread in its own thread group without
success. I suspect that the ORB class creates a new thread in a static
initializer and that all ORB-specific threads are children of this static
thread. In any case, all of the "JavaIDL Listener" threads are in the main()
method's thread group, rather than the thread group of the thread making the
ORB.init() call.

The next approach, which I realize isn't a good one, was to scan the default
thread group for threads with name "JavaIDL Listener" and kill 'em. "Kill" in
this case means first interrupting each thread with this name, with a yield()
after each interrupt() to give the interrupted thread time to react. After the
interrupt loop I re-enumerated the threads and again looked for the listener
threads, this time calling stop() on each. After the stop() loop I call
System.gc().

With this latter approach in place (that is, interrupt() and stop() based on
thread name), I observe the following:

o The count returned by the thread group's activeCount() method increases over
time. It doesn't always increase each time I create a new ORB, but it does
increase, sometimes by more than one, every so often.

o The number of threads returned by the thread group's enumeration() method is
constant, with only a single listener appearing.

o The number of threads and the total VM in use as reported by WinNT's task
manager increases slowly over time. The increase isn't monotonic -- both of 'em
go up and down. However, the maximum and minimum displayed for each (threads
and VM used) increases slowly until I kill the Java VM running Q. When Q's not
running both the thread count and VM used are essentially static.

So, it appears to me that there's a problem with thread cleanup that may be
WinNT specific. However, I'm reporting this as an ORB bug, since the ORB should
be cleaning up after itself in the first place.
(Review ID: 100634)
======================================================================