|
Oracle® Containers for J2EE Configuration and Administration Guide
10g Release 3 (10.1.3) Part No. B14432-01 |
|
 Previous |
 Next |
|
Oracle® Containers for J2EE Configuration and Administration Guide
10g Release 3 (10.1.3) Part No. B14432-01 |
|
|
Previous |
Next |
This appendix describes common problems that you may encounter when using OC4J and explains how to resolve them. It includes the following topics:
This section describes common problems and solutions. It contains the following topics:
Application Performance Impacted by Garbage Collection Pauses
OC4J Hangs When Starting Applications in Oracle Application Server
Problem
"Out of memory" errors indicate that the heap size of the Java instance is lower than the memory required by applications running within OC4J.
Solution
Increase the heap size for the OC4J process to the desired amount of memory at OC4J startup:
java -Xms512m -Xmx512m -jar oc4j.jar
If running in an OPMN managed environment these JVM settings are defined within a <data id="java-options"> tag the opmn.xml configuration file. For example:
<ias-component id="OC4J">
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-Xms512m -Xmx512m -Djava.awt.headless=true
-Dhttp.webdir.enable=false"/>
...
</category>
...
</module-data>
</process-type>
</ias-component>
If running under Unix/Linux, verify that ulimit settings allow the JVM process to allocate this much memory.
Problem
An application running on OC4J appears unresponsive, with simple requests experiencing noticeable delays. The cause is that the JVM has crossed the low memory threshold and is running a full garbage collection to free up memory.
Solution
Consider using the incremental low pause collector, which avoids long major garbage collection pauses by doing portions of the major collection work at each minor collection. This collector (also known as the train collector) collects portions of the tenured generation - a memory pool holding objects that are typically collected in a major collection - at each minor collection. The result is shorter pauses spread over many minor collections.
Note that the incremental collector is even slower than the default tenured generation collector when considering overall throughput.
To use the incremental collector, the -Xincgc option must be passed in on the Java command line at application startup. Set the initial and maximum size of the young generation (object pool) to the same value using the XX:NewSize and -XX:MaxNewSize options. Set the initial and the maximum Java heap sizes to the same value using the -Xms and-Xmx options.
For example, to use this collector with a server with 1 GB of physical memory:
java -server -Xincgc -XX:NewSize=64m -XX:MaxNewSize=64m -Xms512m -Xmx512m
For more information on garbage collection tuning, read "Tuning Garbage Collection with the 1.4.2 Java Virtual Machine" which is available at http://java.sun.com/docs/hotspot/gc1.4.2/
Problem
If the OC4J process memory is growing consistently during program execution, then you may have references to invalid symbolic links in your global application.xml file. This problem is usually characterized by a growth in the C heap and not a growth in Java object memory, as one would see with a more traditional Java object memory leak. OC4J loads all resources using the links in the application.xml file. If these links are invalid, then the C heap continues to grow, causing OC4J to run out of memory.
Solution
Ensure that all symbolic links are valid, and restart OC4J.
In addition, keep the number of JAR files OC4J is configured to load to a minimum. Eliminate all unused JAR files from the configuration and from the directories OC4J is configured to search. OC4J searches all JAR files for classes and resources, thereby causing the file cache to use extra memory and processor time.
Problem
Most class loading errors are related to class visibility—either too much or not enough. Collisions between classes packaged in multiple JARs or inherited by default from parent applications can be a problem.
Solution
Chapter 3: Utilizing the OC4J Class Loading Framework in the Oracle Containers for J2EE Developer's Guide contains detailed documentation on avoiding and troubleshooting class loading-related issues. It also explains how you can use shared libraries to avoid many of these issues within OC4J.
Problem
An error similar to the one below is seen at OC4J startup:
05/10/28 13:58:49 Error initializing server: Error initializing ejb-modules: Error generating wrappers for file:/C:/oc4j/j2ee/home/applications/admin_ejb.jar: javac.exe not found under <directory>, please use a valid jdk or specify the location of your java compiler in server.xml using the <java-compiler .../> tag
Solution
The error indicates that OC4J is unable to locate the required JDK. To resolve this issue, start OC4J from the javac.exe location on the command line. This will set the location of the JDK.
For example:
C:\ORACLE_HOME\j2ee\home\C:\<jdk>\bin\java -jar oc4j.jar
Problem
The following error is thrown when clustering is configured for an application:
WARNING: The service implementation <classname> does not implement java.io.Serializable. *This class is not suitable for clustered environments* indicated by recoverable=true.
Solution
This error indicates that the class is not serializable, and therefore cannot utilize the OC4J replication framework.
Problem
The following error occurs when configuring an OPMN-managed OC4J instance installed as a component of Oracle Application Server, which uses the JDK 5.0 by default, to use the JDK 1.4.2.
oracle.oc4j.loader.util.AnnotatedLinkageError: MBeanServerEjbHome_StatefulSessionHomeWrapper1 (Unsupported major.minor version 49.0)
Solution
An OPMN-managed OC4J instance installed as a component of Oracle Application Server will use the JDK 5.0 by default. This new version of the JDK is required to utilize EJB 3.0 and offers numerous performance improvements. However, if applications that will be deployed to OC4J require a JDK 1.4.2 release, it may be necessary to "downgrade" to the earlier version.
Before switching from JDK 5.0 to JDK 1.4.2, you must remove all compiled application files from the OC4J instance. To do this:
Stop the OC4J instance.
Delete the ORACLE_HOME/j2ee/instance/application-deployments directory.
Deleting this directory will cause the application files to be re-compiled when OC4J is re-started with the JDK 1.4.2.
Problem
In an OPMN-managed environment, OPMN appears to "hang" while trying to start OC4J, resulting in a error similar to the following:
ias-component/process-type/process-set:
OC4J/home/default_group/
Error
Process (index=1,uid=2012873812,pid=2988)
time out while waiting for a managed process to start
Solution
An application that requires significant resources—such as an application that attempts to acquire multiple database connections for its various components—can cause OC4J to fail to start. You can manage this by specifying the maximum amount of time to allow applications to start in the <start-timeout> element defined for the OC4J instance in opmn.xml. After this value is reached, the application will not be started. This value will be applied to all applications deployed to the instance.
The following example increases the start time value to 1000 seconds for applications deployed to the home OC4J instance:
<ias-component id="OC4J">
...
<process-type id="home" module-id="OC4J" status="enabled">
...
<start timeout="800" retry="2"/>
</process-type>
</ias-component>
You can search for additional solutions on the following Oracle support-oriented Web sites:
Oracle Application Server Release Notes, available on the Oracle Technology Network at http://www.oracle.com/technology/documentation/index.html
Oracle MetaLink, available at http://metalink.oracle.com
If you still cannot find a solution for the problem you are facing, please log a service request.
