This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
~Yoshi Asafreemanikle 20.Oct.03 08:53 AM a Web browser Toolkits6.0.3All Platforms
I've been having problems redeploying a J2EE app that forks off threads to create new sessions for a connection pool. Basically, the initial deploy works, but the IIOPConnection(s) in the ConnectionTable doesn't seem to want to release the connections and allow the classloader to be garbage collected on app undeploy/redeploy. The end result is either a hang on undeploy or this exception when trying to create a new orb from the NotesFactory on redeploy:
org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation lotus.priv.CORBA.iiop.ORB minor code: 0 completed: No
at org.omg.CORBA.ORB.create_impl(ORB.java:281)
at org.omg.CORBA.ORB.init(ORB.java:323)
at lotus.domino.cso.Session.createORB(Unknown Source)
at lotus.domino.NotesFactory.createORB(Unknown Source)
at lotus.domino.NotesFactory.createORB(Unknown Source)
I then reasoned that perhaps the active connections in the orb were preventing garbage collection of the orb and susequently the classloader, and that a new classloader in the redeploy would not be able to get a reference to the running orb, and fail to create one since one was already running. So when I try to release the orb manually with orb.release(), I get:
java.lang.Exception
at lotus.priv.CORBA.iiop.IIOPConnection.cleanUp(Unknown Source)<Oct 20, 2003 4:13:16 AM EDT> <Info> <Deployer> <149210> <The Deployment Slave is resumed
>
at lotus.priv.CORBA.iiop.ConnectionTable.release(Unknown Source)
at lotus.priv.CORBA.iiop.ORB.release(Unknown Source)
at test.DatabaseConnection.connect(Unknown Source)
I even get this when not inside a forked thread, which would lead me to believe that it may be a bug in the IIOPConnection.cleanUp() method. Perhaps, therein, there is even something so silly as an attempt to use the deprecated stop() method on internal threads that have locks. Just a wild guess of coarse. ;)
according to Bruce Eckel:
"One change that was introduced in Java 2 to reduce the possibility of deadlock is the deprecation of the Thread class’s stop( ), suspend( ), and resume( ) methods.
The reason that the stop( ) method is deprecated is because it doesn’t release the locks that the thread has acquired, and if the objects are in an inconsistent state (“damaged”), other threads can view and modify them in that state. The resulting problems can be subtle and difficult to detect. Instead of using stop( ), you should use a flag to tell the thread when to terminate itself by exiting its run( ) method."
At this point I have no choice but to not fork off my connection factory, and pray that my app does not come to a grinding halt waiting for a 3 minute timeout if it cannot connect to a domino server that may be down.