JDK-6687374 : Java Console goes off after pressing F5 when applet is loaded in IE
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-04-11
  • Updated: 2010-04-04
  • Resolved: 2008-05-18
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.
JDK 6
6u10Resolved
Related Reports
Duplicate :  
JDK-6695076 - Applet is not getting loaded in IE with New Java Plugin (2nd)
Relates :  
JDK-6690729 - Applet is not getting loaded in IE with New Java Plugin
Description
How to reproduce

1.) Install JRE 6u10 b21 and Open an applet in IE (6 or 7)
http://www.csm.ornl.gov/java/book/applets/Abacus/
2.) Open Java Console from System Tray
3.) Click F5 multiple times (Some time it goes off in first try it self)

Console will go off. I have tried on WIN XP and 2K and could reproduce it. Once i got AppletLifeCycley Exception as well. After that, i couldn't get that exception again.
Comments
EVALUATION Not reproducible with current code. Closing as duplicate of 6695076.
18-05-2008
EVALUATION This has likely been fixed with the fixes for 6690729 / 6695076. Should re-test and then close as a duplicate of one of the others if so.
15-05-2008
EVALUATION I was able to reproduce this problem with my development build. It's possible my workspace is out of date, but the indication I saw was that the client JVM didn't receive a heartbeat back from the browser (server) side and tore itself down. The heartbeat messages from the client to the server were originally needed to guarantee prompt teardown of the attached JVMs when we were using the shared memory transport on Windows. Now that we are using named pipes, and receive an IOException promptly when the connection is broken on one side (similar to how the Unix port works), the heartbeats are less necessary. At a minimum we should probably increase the heartbeat timeout on the client side to reduce the risk of inadvertent teardowns. We might want to see if there is some underlying bug causing the browser to take too long to respond to those heartbeat messages in some situations.
11-04-2008
EVALUATION I'm able to reproduce the problem with 6u10 b21. The problem is easier to reproduce if one selects the "Do not start console" from the java control panel, and starts java console from the system tray after the applet has been loaded. From the plugin trace, the "Pipe worker thread" has been terminated due to IOException on both the attached JVM and the browser side. Attaching a plugin trace for the attached JVM. The browser side exception is as follows: Terminating Java Plug-In Pipe Worker Thread (Server-Side) due to exception: java.io.IOException: Error reading from named pipe at sun.plugin2.ipc.windows.WindowsNamedPipe.read(Unknown Source) JVM instance for 1.6.0.10 exited at sun.plugin2.message.transport.NamedPipeTransport$SerializerImpl.read( Unknown Source) at sun.plugin2.message.transport.NamedPipeTransport$SerializerImpl.readB yte(Unknown Source) at sun.plugin2.message.AbstractSerializer.readInt(Unknown Source) at sun.plugin2.message.transport.SerializingTransport.read(Unknown Sourc e) at sun.plugin2.message.Pipe$WorkerThread.run(Unknown Source) JVMInstance (1.6.0.10) processing StartAppletResultMessage with: appletID: 7, status: loaded Drain AppletMessage: sun.plugin2.message.SetAppletSizeMessage@5 JVMInstance (1.6.0.10) processing StartAppletResultMessage with: appletID: 8, status: loaded JVMInstance (1.6.0.10) processing StartAppletResultMessage with: appletID: 7, status: started JVMInstance (1.6.0.10) processing StartAppletResultMessage with: appletID: 8, status: started The problem doesn't reproduce with the current nightly build at: http://oklahoma.east/reports/builds/nightly/1.6.0_10/nightly/2008-04-10.08_41 so this problem seems to have been fixed by recent bug fixes since b21. Lowering the priority to P4.
11-04-2008