I recently had to troubleshoot an old applet that was not working as expected. I intended to leverage JDeveloper to debug the applet utilizing JPDA socket debug steps listed in: http://docs.oracle.com/javase/6/docs/technotes/guides/plugin/developer_guide/debugger.html
I was able to successfully connect/attach to the VM from JDeveloper and start stepping through code, however within a minute or so, the applet would unexpectedly terminate. You can imagine how frustrating this was. A quick search on google listed possible causes such as browser plugin watchdogs, need for administration privileges, JRE bugs etc. etc.
It turns out the problem was caused due to a breakdown in the heartbeat messages sent between the browser VM and client VM. Invoking the browser with the environment variable JPI_PLUGIN2_NO_HEARTBEAT=1 enabled the debugging to proceed as intended without the applet/Java-plugin being killed / terminating.
Below are the steps I performed to successfully debug an applet:
From Windows Control Panel choose Java > "Java" tab > "View..." button for Java Runtime Environment Settings
Double click table column value for Runtime Parameters for the user JRE entry.
Set the value as
Click "Apply" on the Java Runtime Environment Settings page
Click "OK" on the Java Runtime Environment Settings page
"Advanced" tab > Settings > Debugging
"Advanced" tab > Settings > Java console
Choose Show console
Having configured the JRE options, we now need to disable that heartbeat message mechanism before we launch the browser. As mentioned above, failure to perform this will result in the Applet / JRE abnormally terminating typically under a minute or so of stepping in to code.
You will likely see an exception along the lines of
basic: JVM[id=0]-Heartbeat heartbeat dead, exception. dT=NNN seconds.
And then launch browser, e.g.
e.g. C:\Users\mshannon\AppData\Local\Google\Chrome\Application\chrome.exe --disable-hang-monitor
The "--disable-hang-monitor" option passed to Chrome prevents it from popping up the ‘plugin not responding’ dialog.
Additional command-line options for Browser JVM Troubleshooting can also be set; These result in verbose console messages such as rendering the parameters supplied to the applet.
Check for JRE logs/traces in %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\log
Once I was able to properly step through code, I found the cause of the problem with our applet. The applet was no longer able to obtain from the browser an OAM 11g webgate cookie which had been set to be httponly.