The root cause of the intermittent failures to relaunch JNLP applets
is a race condition introduced by the new semantics of the
HeartbeatMessages sent from the atttached JVM instances back to the
browser as part of the fix for 6663106.
To fix the problem, the HeartbeatMessage has been simplified to no
longer contain a list of running applets. The
StartAppletReponseMessage sent from the attached JVM to the browser
has been simplified to a StartAppletAckMessage, and the browser is no
longer informed of state changes to the applet, since for better
robustness it should not know this information. From the browser's
point of view, the applet is running as long as the web page
containing the applet is being viewed. Failure modes of LiveConnect
have been verified to still work correctly and not hang the browser.
The associated base class of the test cases was updated to work
correctly; it needed to perform its validation in init(), since
LiveConnect calls are enabled immediately after init() completes.
Improved debugging output.
The failures to re-launch JNLP applets are occurring due to a race condition caused by a change in semantics of HeartbeatMessages being sent from the client JVM back to the browser JVM introduced in 6663106. The sequence of operations that causes the failure is:
- The browser starts to launch a JNLP-based applet (call it ID 3)
- It sends a StartAppletMessage to the client JVM instance
- The client JVM instance sends back a heartbeat message that doesn't contain applet ID 3 since it hasn't received and processed the StartAppletMessage yet
- The browser receives this HeartbeatMessage not containing applet ID 3 and removes its plugin instance from the map of active applets for that JVM instance
- Later, the applet requests a relaunch and sends back a StartAppletMessage to the browser, but the browser no longer has a registered plugin instance for that applet ID, so the relaunch fails
There is too tight a coupling between the browser side code and the attached JVM instances. The browser side code needs to be more resilient to failures in the client side code and the client side code should ideally not be able to induce state management failures in the browser side code.