Details
-
Bug
-
Resolution: Fixed
-
P3
-
6u10
Description
FULL PRODUCT VERSION :
Java Plug-in 1.6.0_10-rc
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
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.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
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.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
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.
ACTUAL -
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.
REPRODUCIBILITY :
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 {
Thread.sleep(1000);
} catch ( Exception e ) {
e.printStackTrace();
}
}
}
};
t.start();
}
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:
<html>
<head>
<title>threadapplet</title>
</head>
<body>
<h2>ThreadApplet page</h2>
<applet code="ThreadApplet" codebase="." height="100" width="150" name="ThreadApplet">
<param name="legacy_lifecycle" value="true">
</applet>
</body>
</html>
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
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.
Java Plug-in 1.6.0_10-rc
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
A DESCRIPTION OF THE PROBLEM :
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.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
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.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
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.
ACTUAL -
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.
REPRODUCIBILITY :
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 {
Thread.sleep(1000);
} catch ( Exception e ) {
e.printStackTrace();
}
}
}
};
t.start();
}
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:
<html>
<head>
<title>threadapplet</title>
</head>
<body>
<h2>ThreadApplet page</h2>
<applet code="ThreadApplet" codebase="." height="100" width="150" name="ThreadApplet">
<param name="legacy_lifecycle" value="true">
</applet>
</body>
</html>
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
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.
Attachments
Issue Links
- relates to
-
-
- Closed
-