JDK-6609036 : Add more heartbeats to the system
- Type: Bug
- Component: deploy
- Sub-Component: plugin
- Affected Version: 6u5
- Priority: P3
- Status: Closed
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2007-09-25
- Updated: 2010-09-08
- Resolved: 2008-06-16
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.
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 |
|---|
6u10 b09Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
We have run into a couple of bugs where the main loop in the PluginMain class locked up due to EventQueue.invokeAndWait() being called. In this situation we will be unable to run any more applets in this JVM instance, and the browser will become unresponsive because it will wait several seconds for some message acknowledgments that will never come. To guard against this inadvertently happening in the future we should add a per-JVMInstance heartbeat thread similar to that already in the client JVM process. Probably the pauses between the heartbeats should be longer than in the client JVM process, since this is only intended as a measure of last resort. If the browser-side code determines that a given JVMInstance is unresponsive, it should use Process.destroy() to terminate it. The existing code on the browser side will handle the necessary cleanups.
Comments
|