For modern browsers which support tabs, each tab might be a separate browser process. If a Java applet is embedded in a browser page and the next generation plugin is being used, usually the process associated with the browser tab creates a JVM within the process (browser VM). The browser VM will create another JVM process (client VM) which will run the applet and manage the applet's life cycle. The client VM is a Java process (java.exe on Windows and java on Oracle Solaris/Linux platforms).
The following are some problems with Applets and troubleshooting techniques.
If your applet does not start, make sure to enable tracing and the Java console as explained previously. Then use hits below to find reason why applet does not work.
Do you get a trace file generated or see the Java console?
No, I don't get a trace file
Check if Java technology is detected, see
Yes
Look at JVM browser issues from
No
It is likely to be a configuration issue. See for common configuration problems and if it does not help, look at JVM browser issues from
Yes, I have a trace file
It is unlikely to be a configuration issue (unless you have the new generation plugin disabled). The problem is likely to be specific to this applet. Try to launch some other applets to confirm. Look at JVM client issues from
A crash could be caused by a platform or application issue.
Typically, if a crash happens in the JVM then there should be hs_err_*log file created in the current working directory (on Windows it is often placed on the desktop). It is the same crash report file as for standalone applications. For details about the report file, see Appendix A.
If you can spot native libraries loaded from the deployment cache directory, especially if you see code from these libraries in the crash stack, it is very likely to be a bug in the application.
Otherwise it is a JRE bug and needs to be reported to Bug Database.
The following are two scenarios to consider for a crash by platform or application issue.
JVM browser issues: Get more details about a JVM running in the browser process. Set the following two environment variables before starting the browser:
JPI_PLUGIN2_DEBUG=1 JPI_PLUGIN2_VERBOSE=1
On Windows, there should be a command window associated with the browser process. All browser VM debug output goes into the command window. Check to see if any exceptions are visible there. A Java thread dump can be obtained by using the Control+Break key sequence on the command window.
On Oracle Solaris or Linux platforms, after setting the above variables, start the browser from the same session. All browser VM debug output goes into the terminal window. To get a Java thread dump, on a separate terminal, use kill -3 pid or kill -SIGQUIT pid, where pid is the process id of the browser process.
There are "heartbeat" messages sent between the client VM and browser VM. The "heartbeat" messages can be turned off by setting the JPI_PLUGIN2_NO_HEARTBEAT environment variable to 1. This will help isolate whether the problem is related to the "heartbeat".
If the log is not opening and environment variables are set in the browser process, then it is likely that the JRE is not installed correctly or Java is disabled. Check for configuration errors and try to reinstall the JRE if nothing else helps.
JVM client issues: Check the latest trace file for ideas.
Note: The same client JVM may be shared between multiple applets. Sometimes intermittent failures happen because the shared JVM does not have enough resources available (for example, heap size). In that case, a page reload often helps to resolve the problem.
If application fails with an Out of memory error, the heap size needs to be increased. This can be done in the application deployment descriptor (JNLP file) or in the Java Control Panel using Runtime Parameters for JRE in use.
If an application is signed and the user declined a security dialog, this may cause application failure. The decision made by the user is remembered until the JVM is restarted. To see the security dialog again, the user may need to restart the browser.
Note: An applet can be deployed to reduce the risk of being affected by other applets and tailor execution environment for the applet's needs. See Applet Deployment in the JDK documentation. In particular, consider using the separate_jvm parameter argument.
The following are scenarios that could cause an unresponsive web page.
Frozen applet at applet start or during runtime:
The cause for a frozen applet at applet start or during runtime could be Liveconnect calls.
On startup, an attempt to access the Java applet from JavaScript may block the JavaScript engine until the applet initialization is complete. It is recommended to postpone JavaScript access until the applet is ready and use the enableStatusEvents parameter to unlock non-blocking access to applet status checks. See Applet Status And Event Handlers for details and examples.
To use Liveconnect in runtime, it is recommended to make JavaScript calls return quickly to avoid blocking the single-threaded JavaScript engine.
Applet or browser hangs:
The best source of information in this case is the stack state for both client and browser JVMs.
Use jstack to collect the JVM stack status for the browser JVM (by running jstack browser-pid) and client JVM. Note: The jstack may highlight a deadlock if it happens in context of one of these VMs, but it cannot do this if the deadlock involves both processes. In this case, the thread stacks need to be examined manually. See for more details.
For other approaches, see
