EVALUATION
This test case uncovered several lurking problems in the new plugin's
shutdown sequence, mostly related to LiveConnect calls. First, there
was a blocking call to the applet's Event Dispatch Thread from the
main thread on the client side (the JVM instance executing the
applet), which was a potential source of deadlocks and which was what
made this test case appear to hang the browser. In fact, the browser
would recover after some 20 seconds, but would thereafter be unable to
execute any more applets since the subordinate JVM would be
deadlocked. Second, LiveConnect capabilities were being shut down for
applets too early; applets need to be able to make LiveConnect calls
during Applet.stop(), though according to current specifications
should not be able to do so afterward, for example, in
Applet.destroy(). Third, on the browser (server) side, the sending of
the StopAppletMessage and waiting for its acknowledgment were blocking
without processing incoming messages from the client, also preventing
Java-to-JavaScript calls from being made during Applet.stop(). The
latter was the deepest root cause for the behavior seen originally.
The Applet.stop() handling on the browser side has been split into two
portions with platform-dependent code run in the middle to process
incoming requests, in similar fashion to how JavaScript-to-Java calls
work. On the client side the termination of LiveConnect capabilities
has been moved to the correct place in the shutdown sequence. A
lurking potential problem in the implementation of
MozillaPlugin.invokeLater() on Unix platforms (which may soon be used
on Windows as well) has been fixed. Other associated fixes and
cleanups have been made. Tested with IE and Firefox on Windows and
Firefox on Solaris/x86.
|
Java