JDK-6727020 : Intermittent reliability problems related to applet relaunching
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-07-17
  • Updated: 2010-09-08
  • Resolved: 2008-09-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u10 b32Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Reliability problems have been seen that appear to be related to re-launches that occur for applets launched via JNLP. 6723194 describes some of the scenarios in which the problems have been seen. Due to the need to minimize changes in 6u10 at this point in the release cycle, the fix for 6723194 will only cease throwing InternalErrors, but not actually diagnose the root cause of why those InternalErrors were raised. It is critically important to have high reliability and to understand why intermittent problems are being seen in stress situations such as launching multiple applets on the same web page that all use JNLP and which cause relaunches.

The Scene Graph demos at http://scenegraph-demos.dev.java.net/demo-applets.html , linked from https://jdk6.dev.java.net/plugin2/#DEMOS , have been seen to demonstrate the problem.
Investigation during the fix of 6723194 indicates that the root cause of this problem might be duplicate relaunch messages being sent for a particular applet instance. More investigation is needed.

EVALUATION 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.

SUGGESTED FIX testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_11/6727020/ webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u11/6727020.0

EVALUATION 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.