United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6727020 Intermittent reliability problems related to applet relaunching
6727020 : Intermittent reliability problems related to applet relaunching

Details
Type:
Bug
Submit Date:
2008-07-17
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-09-30
Component:
deploy
OS:
generic
Sub-Component:
plugin
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10

Related Reports
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

                                    

Comments
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
                                     
2008-09-01
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.
                                     
2008-09-01
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.
                                     
2008-08-31



Hardware and Software, Engineered to Work Together