JDK-6642981 : Excessive CPU consumption during some shutdown situations
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2007-12-18
  • Updated: 2010-09-08
  • Resolved: 2008-01-11
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 b10Fixed
If the environment variable JPI_PLUGIN2_DEBUG is set, thereby causing a DOS console to be opened for the new plug-in's debugging output on the browser side, and if the user has the QuickEdit mode set and inadvertently clicks in the text area of that window, some text may end up getting selected. This will cause the browser-side code to hang attempting to print output to the DOS console, and heartbeat messages will not be returned to the attached JVMs. The attached JVMs will then think the browser side has exited, and will shut themselves down, cancelling the conversation associated with the last heartbeat message. If the right mouse button is then clicked in the DOS console, resuming the processing on the browser side, then during the time duration those attached JVMs are in the process of shutting down, the system will furiously pass the heartbeat message back and forth between the two processes, consuming 100% CPU. Further, the browser side code will attempt to kill the attached JVMs even after they have exited. This behavior obstructs debugging and should be fixed.

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u10/6642981.0

EVALUATION Added checks during shutdown to avoid pingponging an abandoned HeartbeatMessage back and forth, and to avoid killing an already-exited subordinate JVM process.