|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
|
Previous |
Next |
This section contains the following:
If the Forms applet disappears unexpectedly, accompanied by a dialog indicating a fatal error, then the Forms applet has crashed. On Windows, a crash will result in the operating system raising an 'illegal operation' dialog, or may cause the "Not responding" flag in Task Manager.To verify the crash, check for a stack trace file on the client. If the client has crashed then a file with the .rpt extension will be created in the same directory as the executable. The root of the filename will be the name of the executable. If you're using Appletviewer that was started from the directory c:\jdk\1_3_1\bin, the client stack trace file will be c:\jdk\1_3_1\bin\appletviewer.rpt.
If you're using JInitiator, then the executable is considered to be the Web browser. If the browser is Netscape, the client stack trace file will be netscape.rpt, whereas for Internet Explorer it will be iexplore.rpt.
Sometimes the applet may appear to have crashed, but no corresponding .rpt file can be found. In this case it is likely that the Oracle Forms Server process has unexpectedly disconnected from the client. The applet will still be running, but it has shutdown all the Forms windows, giving the appearance of a client crash.
If the client appears to hang then it is important to verify that the server process is still alive. If the server process has not crashed, but the client no longer appears to respond to user interaction then the application is said to be hanging.
In such cases a thread dump can point to the deadlock.
The information contained in the dump file is extremely useful to Oracle development, and should be included in any bug filed to report the problem.
One cause could be a mismatch between the Java class files and the Oracle Forms server version. Communication between the applet and the Forms server process is based on message ID. If these message ID's are out of synch, then the applet may not understand an instruction from the server, and vice versa. If you are using Jar files, then try with the <ARCHIVE> tag removed. If the problem persists then pull the correct class files off the installation/patch CD by hand.
Another cause is that the Forms Runtime Process may have died. Check if the Forms Runtime Process on the server is still alive. Check that the FORMS_TIMEOUT parameter is set. The timeout facility acts like a heartbeat and expects the Oracle Forms client to 'ping' the server on a set interval, only cleaning up the Oracle Forms Server process when there has been no activity from the Forms client for the specified time. Although this is primarily intended to prevent orphaned server processes, it can also prevent the unwanted premature cleanup of server processes.
A stack dump can be obtained from an Appletviewer by pressing CTRL+BREAK in the command prompt (or DOS session) that you started the Applet-viewer from.
For JInitiator, the Java console shows how to output dump information. Follow the onscreen instructions to view it.
The information contained in the thread dump can help Oracle development identify the problem in the code. The thread dump should be included in any bug filed to report the problem.
