FULL PRODUCT VERSION :
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows (All)
Cannot test on other platforms, but it probabily can happen on any platform

A DESCRIPTION OF THE PROBLEM :
The problem is thus:

when moving away from, or refreshing, certain applets (AWT Applet with some Swing components) the JVM appears to terminate (a new plugin system tray icon appears and then the intial one dissapears.) This results in session state being lost forcing our users to log into the product again. There is no stack trace in JDK/JRE 6u10 or below. However in JDK7 b40 an exception (IllegalMonitorStateException) does occur (in DelayQueue from TimerQueue - javax.swing - ), the JVM keeps running (since it's still using plugin 1, see below) but unspecified random behaviour was observed afterward.

The problem only occurs if the 'Next generation plugin' is enabled, so I read up on the new plugin and found that it is not very forgiving if the applet doesn't respond to being stopped in short order. Initially I thought maybe the applet was doing something wrong and tried all manner of things to try and fix the problem. The only thing I found that helped was when I didn't add half the Panels to the applet, now I know what you're thinking but it doesn't seem to matter which panels I remove only that I remove enough; besides it only breaks with plugin 2 and jdk7.

So I looked into the jre 6u10 source (jaxax.swing.TimerQueue) and found that the TimerQueue thread's run() method breaks when 'running' is set to false, but that the method it executes to perform its job - postExpiredTimers() -:
a. never checks stopped &
b. catches InterruptedException when it calls wait(1)
This means that when stop() is called on TimerQueue the thread may not stop timeously (or, going by the comments in postExpiredTimers(), ever!) particularly if there are more Timers in the queue; The more components the more timers, hence the problem only tends to happen when there are many components realised on the applet.

I believe that in my case the postExpiredTimers() eventually returns; and that the old plugin waits a bit longer, before deciding that the applet is not responding, than the new plugin. My theory is that the new plugin, after deciding that the applet is hung or too slow, calls Thread.stop() resulting in the exception which then results in a new JVM being spawned and the old one being destroyed.

The only JDK with debug options I could find on the sun website was JDK7 - maybe I am blind ;) - so I used it and discovered that TimerQueue has a somewhat different implementation (so it wasn't quite helpful.)

The long and short of it all is as follows:
The problem occurs in JDK/JRE6 update 10 and below, ONLY if the new plugin is enabled; but it is not a fault of the plugin.
The problem always occurs in JDK7 b40 and, although the symptom is different, it only has the old plugin and with the new plugin I am fairly confident that the symptom would be the same.

Please note that I have searched high and low on this bug database and on the forums and on google and although I found some bugs that look similar (that is I think they are caused by the same kind of 'buggy' code; see bug # 6627356 ) they are not the same.

Since there is a workaround (disabling the new plugin) this is not too urgent, BUT obviously we would like to use the new plugin (it's very pretty and sparkly aka FAST! with lots of nice new features) AND although I am only experiencing this with large applets on the new plugin others might be experiencing similar problems due to the issues above and I have at least attempted to find the problem and give a solution.

Please forgive my verbosity, I thought it best to detail everything as best I could.

Also, if you need anything further from me you have my email address.

Please fix this, pretty please with sugar on top. ;)

P.S. Where can one get a debug build of JDK 6u10? And where to get instructions on setting up the jre source's as a project in eclipse or wha'eva? I know this isn't the place but trying to find simple things like that should be easy, then maybe I could test my theories.....

Regards
Daniel

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Unfortunately I don't hae a test case, but basically load a large applet (probably with quite lot of swing components on ) in your browser, with plugin 2 enabled (or using JKD/JRE7.) Hit reload and the jvm will be terminated and restarted.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The Applet (and all its threads noteably TimerQueue ) should stop timeously and the JVM therefore should not be killed.
ACTUAL -
The TimerQueue thread does not stop when its stop() method is called, causing the 'New' plugin, on the assumption that the applet is not responding, to call Thread.stop() (I assume that the resulting ThreadDeathException leaves monitors in an inconsistent state) ultimateley causing the plugin to restart the JVM. This is very undesireable.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Disable the next generation java plugin (and loose a bunch of sparklies :( )

Release Regression From : 6u7
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.