Web Application moved from standalone OC4J to OC4J under AS 10.1.2 quickly becomes unresponsive and gets restarted by OPMN if using <global-thread-pool> tag (Doc ID 352580.1)

Last updated on OCTOBER 27, 2023

Applies to:

Symptoms

You have been using the "standalone" installation type for Oracle Containers for J2EE (OC4J) for some time, where you have an application that is working to expectation. Recently, you have deployed the application to an OC4J instance running as a component of the larger Application Server (AS) installation type, where the OC4J container is managed by the Oracle Process Manager (OPMN) component of the Application Server and accessed by Oracle HTTP Server (Apache) via the MOD_OC4J component.

While running in the Application Server installation topology the OC4J container where your application is running becomes unresponsive to OPMN health check "pings" within a very short period of time (typically 10-15 minutes or shorter depending on the frequency of access).

Your OC4J instance log files under <ORACLE_HOME>/opmn/logs contain no error messages or other indications of a problem. The java process running the OC4J instance is not consuming high CPU, there is no evidence that the java virtual machine has used a high proportion of memory (no java.lang.OutOfMemory), and additional logging from java startup options "-verbose:gc -XX:+PrintGCDetails" do not show high java heap usage or heavy garbage collection operation.

A java stack trace taking while "opmn" is reporting "ping failures" does not show an excessive number of threads or any threads blocking on one another. There are not a large number of sockets opened to OC4J nor a large number of open files.

The OPMN log file "ipm.log" may show repeated error sequences similar to the following:

to the "server.xml" file for the OC4J instance.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.