geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: An interesting discovery about CSSBean.
Date Fri, 14 Jul 2006 19:45:36 GMT
Agreed.
--kevan
On Jul 14, 2006, at 3:24 PM, Dain Sundstrom wrote:

> +1 to make the change (pending tck verification)
>
> -dain
>
> On Jul 14, 2006, at 5:18 AM, 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
>


Mime
View raw message