-
Bug
-
Resolution: Not an Issue
-
P3
-
7u40
-
windows_7
FULL PRODUCT VERSION :
Java Plug-in 10.40.2.38
Using JRE version 1.7.0_40-ea-b38 Java HotSpot(TM) Client VM
ADDITIONAL OS VERSION INFORMATION :
Windows 7 64-bit
Microsoft Windows [Version 6.1.7601]
EXTRA RELEVANT SYSTEM CONFIGURATION :
JPI_PLUGIN2_NO_HEARTBEAT is set in Windows environment vars, but problem occurs with or without.
Most testing with Firefox 23.0.1. Internet Explorer 9 has same problem but seems to recover better and not as prone to browser hang when problem occurs.
A DESCRIPTION OF THE PROBLEM :
When remote debug parameters are configured in the Java control panel, get extra java.exe processes, and a second applet launched from the page of the first applet will fail to launch. When the second applet fails to launch, the browser process and the java.exe processes will be hung and must be terminated in Task Manager.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a simple applet and package it into a self-signed jar file (signed jar is required with 7u40). Create two HTML pages to launch the applet. On the first HTML page, add a link that opens the second HTML page in a new browser window (i.e., " target=_blank " ).
In the Java control panel, configure Java with the remote debug parameters in the Runtime Parameters field of the Java Runtime Environment Settings (from Java tab). The remote debug params are: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
Launch the applet using the first page, get security prompt for self-signed jar file, say Okay. You will now get one java.exe process and a Java console, associated with the security prompt. When the actual applet starts, you get another java.exe process and another Java console, associated with the applet.
If you wait a minute, the first process and console (associated with the security prompt) will terminate on its own. If you exit the browser either before or after the first java.exe process terminates, both the browser process and the java.exe process associated with the applet will terminate. This is the " happy " path.
However, once the first applet is running, if you launch another applet in another browser window from a link on the first applet's page, the second applet will not start. In this path, if you wait for the process associated with the security prompt to terminate before launching the second applet, you get a new security prompt for the second applet and the second applet gets stuck on the spinning Java progress image.
But if you don't wait for the process associated with the security prompt to terminate first, the second applet page comes up completely blank and nothing happens. Once the second applet has attempted to start, if you exit the browser, the browser process and one of the java.exe processes hang and you must use Task Manager to kill the browser process (which will also kill the java.exe process).
If the remote debug parameters are not included in the Java control panel, you get only one java.exe process for the security prompt, the first applet, and any additional applets
that you launch from the link on the first applet's page.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
One java.exe process for all applets launched from the same codebase and all applets start and can be debugged. The browser should exit cleanly, and the browser process and java.exe processes should terminate.
ACTUAL -
Multiple java.exe processes, one for each security prompt and each applet (though any additional applets beyond the first one fail to start). When the failure occurs after launching an additional applet from the same codebase, the browser process and the associated java.exe process hang and must be terminated in Task Manager.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
Source for simple test applet:
import java.awt.*;
import java.util.Date;
import javax.swing.*;
public class ClockFrame extends JApplet
{
public void init()
{
System.out.println( " ClockFrame.init " );
setLayout( new BorderLayout() );
add( getClock(), BorderLayout.CENTER );
}
private JLabel getClock()
{
final JLabel label = new JLabel();
label.setText( new Date().toString() );
new Thread( new Runnable() {
public void run()
{
while( true )
{
try
{
Thread.sleep( 1000 );
label.setText( new Date().toString() );
}
catch( Exception e )
{
// ignore
}
}
}
}).start();
return label;
}
}
-------------
HTML source for launching applets:
<html>
<body>
<applet code= " ClockFrame " codebase= " . " height= " 100 " width= " 150 " name= " ClockFrame " archive= " ClockFrame.jar " >
</applet>
<p>
<a href= " clock.html " target= " _blank " >Second clock</a>
</body>
</html>
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Don't launch a second applet. Not always feasible with our applet deployment model.
Java Plug-in 10.40.2.38
Using JRE version 1.7.0_40-ea-b38 Java HotSpot(TM) Client VM
ADDITIONAL OS VERSION INFORMATION :
Windows 7 64-bit
Microsoft Windows [Version 6.1.7601]
EXTRA RELEVANT SYSTEM CONFIGURATION :
JPI_PLUGIN2_NO_HEARTBEAT is set in Windows environment vars, but problem occurs with or without.
Most testing with Firefox 23.0.1. Internet Explorer 9 has same problem but seems to recover better and not as prone to browser hang when problem occurs.
A DESCRIPTION OF THE PROBLEM :
When remote debug parameters are configured in the Java control panel, get extra java.exe processes, and a second applet launched from the page of the first applet will fail to launch. When the second applet fails to launch, the browser process and the java.exe processes will be hung and must be terminated in Task Manager.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a simple applet and package it into a self-signed jar file (signed jar is required with 7u40). Create two HTML pages to launch the applet. On the first HTML page, add a link that opens the second HTML page in a new browser window (i.e., " target=_blank " ).
In the Java control panel, configure Java with the remote debug parameters in the Runtime Parameters field of the Java Runtime Environment Settings (from Java tab). The remote debug params are: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
Launch the applet using the first page, get security prompt for self-signed jar file, say Okay. You will now get one java.exe process and a Java console, associated with the security prompt. When the actual applet starts, you get another java.exe process and another Java console, associated with the applet.
If you wait a minute, the first process and console (associated with the security prompt) will terminate on its own. If you exit the browser either before or after the first java.exe process terminates, both the browser process and the java.exe process associated with the applet will terminate. This is the " happy " path.
However, once the first applet is running, if you launch another applet in another browser window from a link on the first applet's page, the second applet will not start. In this path, if you wait for the process associated with the security prompt to terminate before launching the second applet, you get a new security prompt for the second applet and the second applet gets stuck on the spinning Java progress image.
But if you don't wait for the process associated with the security prompt to terminate first, the second applet page comes up completely blank and nothing happens. Once the second applet has attempted to start, if you exit the browser, the browser process and one of the java.exe processes hang and you must use Task Manager to kill the browser process (which will also kill the java.exe process).
If the remote debug parameters are not included in the Java control panel, you get only one java.exe process for the security prompt, the first applet, and any additional applets
that you launch from the link on the first applet's page.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
One java.exe process for all applets launched from the same codebase and all applets start and can be debugged. The browser should exit cleanly, and the browser process and java.exe processes should terminate.
ACTUAL -
Multiple java.exe processes, one for each security prompt and each applet (though any additional applets beyond the first one fail to start). When the failure occurs after launching an additional applet from the same codebase, the browser process and the associated java.exe process hang and must be terminated in Task Manager.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
Source for simple test applet:
import java.awt.*;
import java.util.Date;
import javax.swing.*;
public class ClockFrame extends JApplet
{
public void init()
{
System.out.println( " ClockFrame.init " );
setLayout( new BorderLayout() );
add( getClock(), BorderLayout.CENTER );
}
private JLabel getClock()
{
final JLabel label = new JLabel();
label.setText( new Date().toString() );
new Thread( new Runnable() {
public void run()
{
while( true )
{
try
{
Thread.sleep( 1000 );
label.setText( new Date().toString() );
}
catch( Exception e )
{
// ignore
}
}
}
}).start();
return label;
}
}
-------------
HTML source for launching applets:
<html>
<body>
<applet code= " ClockFrame " codebase= " . " height= " 100 " width= " 150 " name= " ClockFrame " archive= " ClockFrame.jar " >
</applet>
<p>
<a href= " clock.html " target= " _blank " >Second clock</a>
</body>
</html>
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Don't launch a second applet. Not always feasible with our applet deployment model.