+1 ...good detective work Rick.
Rick McGuire wrote:
I've been taking some hard looks at all of the places where Geronimo
creates/configures ORB instances as part of an effort to enable Geronimo
for using the Yoko ORB. As a result, I've made an interesting discovery
about how CSSBean is working that might warrant a 1.1.1 bug fix. The
first part of the discovery was an issue I raised a couple days ago
about CSSBean creating 2 ORB instances where 1 would be sufficient.
That change simplified the configuration, and also eliminated one of the
two threads that CSSBean is creating.
The new discovery is that BOTH of the threads that CSSBean creates are
unncessary. The two threads that CSSBean creates merely make a call to
"orb.run()", assuming that run() somehow started ORB execution, and
since it was a blocking call, it needed to work on a separate thread. A
reasonable assumption, but that's not the purpose of run() at all! The
ORB run() method:
This operation blocks the current thread until the ORB has completed
the shutdown process, initiated when some thread calls |shutdown|.
It may be used by multiple threads which get all notified when the
ORB shuts down.
run() doesn't start anything up at all, it merely waits until the ORB is
destroyed. It is not necessary to call run() to use the ORB as a
client, so those two threads don't do anything but sit there and wait
for the two ORB instances to be destroyed. They're not necessary for GC
purposes, because the CSSBean is holding the references (and in fact, is
the code that will eventually issue the destroy() call that will
terminate the 2 threads). As part of the Yoko changes, I've been
reworking this, but there's a pretty good resource boost to be gained,
so it might be worthwhile applying at least the thread removal to the
1.1.1 base.
Rick
