CORBA COMM_FAILURE when destroy() takes too long and close() happens

Test case and related files are in
/net/cores.east/cores/63693175

BEA logged the case and this is reproducible under their application server.
I have it in this directory as well in case it's needed.
server811_solaris32.bin

You can install this installer and choose the default install
location(/usr/local/bea).

After the installation create a directory user_projects under
/usr/local/bea/weblogic81/
create another directory under user_projects by name domains.

Under this domains directory extract the mydomain.zip file which is available in the above directory
/net/cores.east/cores/63693175

  deploy the application 'fxtransact'

   hit the applet in the browser as follows:
   http://host:port/fxtransact/applet.html or
   http://host:port/fxtransact/iiop-applet.html or
   http://host:port/fxtransact/http-applet.html

  4) you will a submit button in the browser. Hit the submit button wait for message that says applet started. And then hit the submit button again. You will see corba errors in java plugin console.


Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe
 
 at com.sun.corba.se.internal.iiop.IIOPConnection.purge_calls(Unknown Source)
 at com.sun.corba.se.internal.iiop.ReaderThread.run(Unknown Source)

On the applet refresh/reload it is trying to do two things at a time. One is calling destroy and the other is an event on killing the whole applet context and it's corresponding resources.
So, One thread is executing destroy() and the other thread is executing cleaning up AppContext. As part of cleaning up app context, it is also killing all the threads and thread groups and hence killing com.sun.corba.se.internal.iiop.ReaderThread. But at the same time, the other thread who is doing destroy() is trying to use the ReaderThread and operating
processInput() on IIOPConnection inside run() method of ReaderThread. Hence it got ThreadDeath. Hence, it is setting SystemException as COMM_FAILURE to the connection and finally it's been thrown from the destroy() method.
 
 So, finallay based on various combinations we tried, looks like it is failing only in the case when both of these are happening at the same time. It doesn't fail if the destroy() or init() happens completely before or after ThreadDeath is issued.