03767: | cannot fully uninstall a stopped component |
Category: Container
Status: ClosedSeverity: HIGH
Reported against release: 0.8
Fixed in release: 0.9.1
PROBLEM:The container appears to hold references to jar files for stopped
processes. Here is the sequence that caused the problem:
1. ran ow.bat and owsh.bat
2. "install image_im.jar". This creates \openwings\image.
3. "process -start image_im"
4. "process -stop image_im-"
5. "uninstall image_im". This deletes everything in the image
directory, but "\openwings\image\lib\image.jar"
This problem occurs regularly on Windows platforms. It has also been
observed on Unix platforms when $OW_HOME is on an NFS mounted drive. ANALYSIS:Each process in a container has its own URLClassLoader. Using a tool
called JProbe Profiler, references to the classloader were located.
These references are mostly held by unexecuted threads (since each
thread contains a reference to its context ClassLoader). The threads
are created and referenced by the reference implementation of Component
Services.
All references to the URLClassLoader need to be cleaned up so that it
can be garbage collected, which will unlock the Jar files in its list
of URLs, allowing the component to be fully uninstalled.
Update (5/13/02):
Some cleanup work was done in the container implementation, but the
problem persists. Further work with JProbe indicated two factors in a
process that would cause the JVM to hold on to the URLClassLoader after
the process is stopped: registering shutdown hooks and opening windows.
With regard to registering shutdown hooks: the use of these is not yet
widespread, but the reference implementation of Component Services does
register a shutdown hook that de-registers services. This is so the
services will be de-registered from the lookup service more quickly
than waiting for leases to expire. Therefore every process that uses
Component Services will experience this bug. To make sure that the
problem was in the JVM and not in my container implementation, I built
a very simple test program and was able to reproduce the bug. Therefore
I submitted a bug report to Sun which was accepted. Here is the link
(requires Java Developer Connection login):
http://developer.java.sun.com/developer/bugParade/bugs/4683187.html
If you want to validate this analysis, try running the NativeDemo
component inside a container - you'll have to modify
the "sharedContainerHint" to "true" in the ICD and restart Openwings.
NativeDemo does not use Component Services, register its own shutdown
hook, or bring up a window. If you start the NativeDemo, stop it and
uninstall the component, the uninstall will complete successfully and
all of the jar files in the lib directory will be deleted.
I'm still working on an analysis/test program for the windowing problem.
Additionally, there may be a workaround for the shutdown hook problem,
I'll update this analysis as I have more info.
Update (5/24/02):
With respect to the shutdown hook issue, there is possible fix: When
running in a container, Component Services can register a callback with
the container instead of registering a shutdown hook with the JVM. Note
that this requires a slight change to the Container Services API, since
only one "ProcessAccess" callback may be registered with the Container.
This would put Component services in the position of competing with the
application to register a ProcessAccess. The suggested API change is to
break the shutdown() method out of the ProcessAccess interface into
another interface, and allow multiple shutdown callbacks to be
registered. This is parallel to how the JVM allows multiple shutdown
hooks to be registered.
When the workaround described above is implemented and tested using a
component such as HelloWorldProvider, the Jar files may be deleted.
However, continued analysis in JProbe shows that the classes referenced
by HelloWorldProvider (mostly Openwings core classes) are still in
memory, and objects held by static reference have not been garbage
collected. Defect 5617 was created to deal with this issue: "Container
memory leak - no class unloading for stopped processes".
With respect to the Swing windowing issue, defect 5616 was created to
deal with this problem: "cannot uninstall components using Swing after
running in container". WORKAROUND:The workaround is to kill the shell and container manager. Then delete
the files. Then restart the shell and container manager.
NOTE: In the Openwings 0.9 release, this defect is partially fixed.
Components that do not bring up windows can be successfully uninstalled
after being run in a container. The problem still exists if your
component displays a window, we're working to resolve this for 0.9.1. |
