"FRM-92101: There Was a Failure in the Forms Server During Startup" Error When Loading Forms [ID 1103744.1]
Oracle Applications Technology Stack - Version: 12.0.6 to 12.1.3 [Release: 12.0 to 12.1]
This problem can occur on any platform.
Error
FRM-92101 : There was a failure in the Forms Server during startup. This could happen due to invalid configuration.
Steps to Reproduce
The issue can be reproduced at will with the following steps:
1:- Log into the E-Business suite.
2:- Choose a responsibility and click a function which loads forms (any form)
Business Impact
The issue has the following business impact:
Due to this issue, forms sessions are being disconnected for up to 100 users.
In the $LOG_HOME/ora/10.1.3/opmn/opmn.log we can see that OPMN is restarting the HTTP server because it has become unresponsive.
The reason that OPMN is restarting the HTTP server is that a shared APPL_TOP is being used, but the recommended settings for the Network-attached storage (NAS) file system have not been implemented.
As the NAS mount gets busier, the HTTP server process becomes swamped and does not respond to OPMN. OPMN then restarts the process, causing all forms users connected to that Application server to fail with the FRM-92100 error.
Self service session users are much less likely to notice the issue as most self service application screens are stateless HTML, so no context is lost when the HTTP server is bounced.
1:- Stop ALL middle tier services
2:- Update the $CONTEXT_FILE and change "s_lock_pid_dir" to a directory on a local disk.
3:- Run autoconfig
4:- Ensure that the NAS device is configured with the correct mount options.
5:- Start ALL middle tier services
6:- Retest the issue.
7:- Migrate the solution as appropriate to other environments.
Applies to:
Oracle Applications Technology Stack - Version: 12.0.6 to 12.1.3 - Release: 12.0 to 12.1Oracle Applications Technology Stack - Version: 12.0.6 to 12.1.3 [Release: 12.0 to 12.1]
This problem can occur on any platform.
Symptoms
Intermittently E-Business suite forms sessions are failing with the errorError
FRM-92101 : There was a failure in the Forms Server during startup. This could happen due to invalid configuration.
Steps to Reproduce
The issue can be reproduced at will with the following steps:
1:- Log into the E-Business suite.
2:- Choose a responsibility and click a function which loads forms (any form)
Business Impact
The issue has the following business impact:
Due to this issue, forms sessions are being disconnected for up to 100 users.
Changes
Implemented a shared application tier file system (shared APPL_TOP)Cause
The OPMN process pings the HTTP server process to check that it is still alive. If OPMN does not get a response from the HTTP server in the timeframe configured by the E-Business suite, it presumes that the HTTP server is down and restarts it, affecting all users connected to that application server.In the $LOG_HOME/ora/10.1.3/opmn/opmn.log we can see that OPMN is restarting the HTTP server because it has become unresponsive.
10/02/16 12:08:22 [libopmnohs] Process Ping Failed:
HTTP_Server~HTTP_Server~HTTP_Server~1 (241450421:15863) [The connection
receive timed out]
10/02/16 12:09:13 [libopmnohs] Process Ping Failed:
HTTP_Server~HTTP_Server~HTTP_Server~1 (241450421:15863) [The connection
receive timed out]
10/02/16 12:09:13 [libopmnohs] Process Unreachable:
HTTP_Server~HTTP_Server~HTTP_Server~1 (241450421:15863)
10/02/16 12:09:15 [pm-process] Stopping Process:
HTTP_Server~HTTP_Server~HTTP_Server~1 (241450421:15863)
10/02/16 12:09:23 [pm-process] Starting Process:
HTTP_Server~HTTP_Server~HTTP_Server~1 (241450421:0)The reason that OPMN is restarting the HTTP server is that a shared APPL_TOP is being used, but the recommended settings for the Network-attached storage (NAS) file system have not been implemented.
As the NAS mount gets busier, the HTTP server process becomes swamped and does not respond to OPMN. OPMN then restarts the process, causing all forms users connected to that Application server to fail with the FRM-92100 error.
Self service session users are much less likely to notice the issue as most self service application screens are stateless HTML, so no context is lost when the HTTP server is bounced.
Solution
To implement the solution, please execute the following steps:1:- Stop ALL middle tier services
2:- Update the $CONTEXT_FILE and change "s_lock_pid_dir" to a directory on a local disk.
For example
<lock_pid_dir oa_var="s_lock_pid_dir">/d01</lock_pid_dir>3:- Run autoconfig
4:- Ensure that the NAS device is configured with the correct mount options.
On Linux, it should be using "nolock" option.
On Solaris, it should be using "llock" option.
On Solaris, it should be using "llock" option.
5:- Start ALL middle tier services
6:- Retest the issue.
7:- Migrate the solution as appropriate to other environments.
No comments:
Post a Comment