JDK-6739758 : legacy_lifecycle applets should not exit after 2 minutes
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-08-21
  • Updated: 2011-02-16
  • Resolved: 2008-10-01
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 :  
Java Plug-in 1.6.0_10-rc

Microsoft Windows XP [Version 5.1.2600]

When legacy_lifecycle parameter is set to true and next-generation Plug-in is enabled in control panel, applet destroy method is called when you browse away from the page that loaded the applet. When next-generation Plug-in is disabled in control panel, browsing away from the page calls only applet stop, and destroy gets called only on browser shutdown.

Create an applet with the standard init, start, stop, and destroy methods. In the init method, spawn a thread that writes a count to the console once per second. Create an HTML page to load the applet, and add the legacy_lifecycle param with a value of true.

If the next-generation Plug-in is disabled in the control panel, loading the applet in the browser will show that the init and start methods are called. Browsing off the page will call the stop method, and the counter thread will continue to run and write to the console. Shut down the browser and the applet destroy method gets called, finally killing the counter thread.

Now enable the next-generation Plug-in in the control panel and load the applet in a fresh browser. When the applet first starts, init and start are called and the counter thread writes to the console. Browse off the page, and the applet stop method is called, but the counter thread continues to run. If you set the console trace level to 5, you'll see the message, "Applet supports legacy lifecycle model - add applet to lifecycle cache", but after about 2 minutes, the applet destroy method gets called and a few seconds later, the VM is exited.

According to the introduction section on https://jdk6.dev.java.net/plugin2/, "The applet class loader cache and the legacy applet lifecycle, required for backward compatibility, are fully supported and the behavior of both has been improved." Therefore, I'd expect that when the legacy_lifecycle parameter is set to true, the applet lifecycle would be the same regardless of whether the next-generation Plug-in or the old Plug-in are used.
As noted above, the applet destroy method is called on an applet that has the "legacy_lifecycle" param set to true, but only when using the next-generation Plug-in. When the next-generation option is turned off in the control panel, the destroy method is not called until the browser shuts down.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Applet source:

import java.applet.Applet;

public class ThreadApplet extends Applet
	private int mCounter;
	private boolean mRunning;

	public void init()
		System.out.println( "init() called." );
		mRunning = true;
		Thread t = new Thread() {
			public void run()
				while ( mRunning )
					System.out.println( "Counter: " + mCounter++ );
					try {
					} catch ( Exception e ) {

	public void start()
		System.out.println( "start() called." );

	public void stop()
		System.out.println( "stop() called." );

	public void destroy()
		System.out.println( "destroy() called." );
		mRunning = false;

HTML for running applet:

<h2>ThreadApplet page</h2>
<applet code="ThreadApplet" codebase="." height="100" width="150" name="ThreadApplet">
<param name="legacy_lifecycle" value="true">
---------- END SOURCE ----------

Problem can be worked around by unchecking "Enable the next-generation Java Plug-in" in the Java control panel. However, this will be burdensome for our customers who would need to instruct their end-users to set this option, or who would need to push out a version of the Plug-in with this option unchecked by default.
After email exchanges with the customer, the problem described above where destroy() is immediately being called is not yet reproducible. However, legacy_lifecycle applets are being destroyed due to the 2 minute timeout period for idle JVM instances. This mechanism needs to be fixed to not do this. Reprioritizing to P3.
Further email exchanges with the customer revealed that they are blocking indefinitely in the stop() method of their applet, and both the classic and new Java Plug-Ins in 6u10 are detecting this as a poorly behaved applet and terminating it hard. The behavior the customer is relying on is unspecified and is described to some degree in 4419491. We have indicated that we will not support this behavior going forward, and that using the legacy_lifecycle parameter will give them the behavior they desire. We will still fix the issue with legacy_lifecycle applets timing out and shutting down after roughly two minutes. The test case for the applet which blocks indefinitely in stop() is attached as immediate-destroy.tar.gz.

EVALUATION Removed expiration logic from Applet2ManagerCache, as customer feedback indicates asynchronous expiration of cached applet instances is undesirable. Left in watchdog timer watching for memory pressure.

SUGGESTED FIX webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u11/6739758.0 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_11/6739758/ *** (#1 of 1): [ UNSAVED ] ###@###.###

EVALUATION I can't reproduce this issue with the given test case using 6u10 build 28 on Windows XP SP2 within either IE 7 or Firefox 3. Please ask the submitter to re-check their test case.