JDK-6720885 : IllegalComponentStateException when fast reloading applet in IE
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: generic
  • Submitted: 2008-06-30
  • Updated: 2010-04-04
  • Resolved: 2009-01-13
Related Reports
Duplicate :  
JDK-6720890 - IllegalComponentStateException when fast reloading applet in IE
Relates :  
JDK-6723985 - Java Process hangs when re-loading applet multipletimes using Kernel JRE
Description
The bug is easier reproducible with kernel vm.  Install kernel jre (jre...-k.exe).  As soon as installer is done, launch MoleculeViewer applet in IE7.  When you see "Additional Components" download dialog, while applet has not loaded yet, click "Reload" button in the browser multiple times.  Make sure Java Console is set to "Open" in your deployment.properties file - this way you'll see exception printed.
java.awt.IllegalComponentStateException: Native resources unavailable
   at sun.awt.windows.WPanelPeer.pRestack(Native Method)
   at sun.awt.windows.WPanelPeer.restack(Unknown Source)
   at sun.awt.windows.WWindowPeer.restack(Unknown Source)
   at java.awt.Container.addNotify(Unknown Source)
   at java.awt.Window.addNotify(Unknown Source)
   at java.awt.Frame.addNotify(Unknown Source)
   at sun.awt.EmbeddedFrame.addNotify(Unknown Source)
   at sun.awt.windows.WEmbeddedFrame.addNotify(Unknown Source)
   at sun.plugin2.main.client.PluginEmbeddedFrame.addNotify(Unknown Source)
   at sun.awt.windows.WEmbeddedFrame.<init>(Unknown Source)
   at sun.plugin2.main.client.PluginEmbeddedFrame.<init>(Unknown Source)
   at sun.plugin2.main.client.PluginMain$StartAppletRunner.run(Unknown Source)
   at java.awt.event.InvocationEvent.dispatch(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)
PluginMain: could not create embedded frame 

After this exception occurs I am unable to load any applets, the browser has to be restarted.  Noticed the problem in b27.
Comments
EVALUATION In both cases - from description and comments - exception occurs when embedded frame and its peer are being created. Exception is thrown from AWT native code, and my guess it happens because of eframe's parent HWND is already destroyed at the moment of eframe creation - for example, by reloading page in browser. I doubt AWT can handle this correctly, we can only detect this error, and it is plugin that must be ready to possible unsuccessful eframe initialization.
24-12-2008
EVALUATION We have attempted to reproduce this bug on Windows Vista SP1 with IE 8 beta and the 6u10 build 28 Kernel VM installer. (We don't believe the use of IE 8 instead of IE 7 is significant). Here are the results: - We can not reproduce the report that all subsequent applets fail to load in the browser. With rapid reloading we were able to provoke many exceptions (as of this writing unclear whether they're the reported ones) but not the behavior that subsequent applets in the browser fail to load. - We were able to provoke very undesirable browser lockups. In one situation where such a browser lockup occurred, the browser was waiting for a JavaScript -> Java operation to complete, but the attached JVM did not respond. At this point, the attached JVM running the applet was consuming 100% of a CPU (so clearly stuck in a busy loop). Unfortunately, that JVM was running the Kernel VM, which does not support the dynamic attach mechanism, so we could not run jstack to debug it. We should seriously reconsider the space savings of removing the dynamic attach mechanism given the lack of debugging support this implies. The browser-side stack trace is attached. Killing the attached JVM allowed the browser to recover. - While performing the rapid applet reloads, we frequently saw the UAC dialog asking to allow jbroker.exe to run. These were probably being produced by the repeated launches of java.exe processes in which to run applets. We don't understand why new jbroker.exe processes were being launched. It seems it is exiting too early in some situations. This bug is being recategorized into the Java Kernel category.
06-08-2008