Category: Container
Status: Closed

Severity: HIGH
Reported against release: 0.8
Fixed in release: 0.8.1 (Beta Refresh)

PROBLEM:

When running more than one GUI program in the container several 
anomalies occur.

1.  Hitting window close or calling system.exit(0) from one GUI will 
kill all GUI windows (to test run helloworld user and launcher).  
2.  The processes however remain zombies in the process list and cannot 
be stopped.  The following exception occurs when trying to stop the 
processes:
----------------------------------------
java.rmi.RemoteException
        at 
com.mot.openwings.container.remote.RemoteContainerConnectorUserProxyI
mpl.stopProcess(RemoteContainerConnectorUserProxyImpl.java:99)
        at 
com.mot.openwings.container.remote.RemoteContainerSmartProxy.stopProc
ess(RemoteContainerSmartProxy.java:669)
        at com.mot.openwings.container.remote.RemoteProcess.stop
(RemoteProcess.j
ava:139)
        at 
com.mot.openwings.container.manager.ContainerProcessHandle.stopProces
s(ContainerProcessHandle.java:172)
        at 
com.mot.openwings.container.manager.ContainerManagerCore.stopProcess(
ContainerManagerCore.java:389)
        at 
com.mot.openwings.container.remote.RemoteManagerConnectorProviderProx
yImpl.stopProcess(Unknown Source)
        at java.lang.reflect.Method.invoke(Native Method)
        at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
        at sun.rmi.transport.Transport$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Unknown Source)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown 
Source)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run
(Unknown Sour
ce)
        at java.lang.Thread.run(Unknown Source)
-------------------------------------
3.  After this no programs can be started in the container manager.

ANALYSIS:

The Container program is designed to trap System.exit() calls from 
processes running inside the Container. It does this by overriding the 
checkExit() method in its SecurityManager. When this method is called, 
the Container attempts to determine the current thread and map this 
back to a particular process. If the process can be identified, then it 
is stopped.

The problem in this case is that the System.exit() call is being made 
from the AWT event thread, since the process's window has registered a 
windowClosing() callback with AWT. The Container cannot identify which 
process is responsible for the call, so the entire JVM exits.

What is needed is a way to determine the process responsible even if 
the System.exit() call is coming from a JVM-level thread like the AWT 
event thread. The probable way to do this involves being able to access 
the call stack, identify the classes of calls on the stack and then the 
class loaders involved. If we have the ClassLoader, we can map this 
back to the process, since we know the ClassLoader for each process.

WORKAROUND:

To workaround this problem, start processes with GUIs as standalone 
processes. Edit component descriptors for these processes and change 
the "sharedContainerHint" parameter to false.

back to top

home | vision | search | in the news | faq | registration | open forum | tutorial | bug database
 API | download | expert teams | process management office | projects | links | terms of use

© Copyright 2001-2006 General Dynamics C4 Systems. All rights reserved.