Skip Headers
Oracle® Containers for J2EE Configuration and Administration Guide
10g (10.1.3.5.0)
Part Number E13978-01
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
View PDF

A Troubleshooting OC4J

This appendix describes common problems that you may encounter when using OC4J and explains how to resolve them. It includes the following topics:

Problems and Solutions

This section describes common problems and solutions. It contains the following topics:

Warning Regarding Maximum Concurrent Timers

Problem

A warning such as the following example can occur when the number of concurrent timers exceeds the maximum:

WARNING J2EE OJR-10002

The number of concurrent Timers has reached the maximum limit

By default, OC4J 10g (10.1.3.5.0) allows only eight concurrent timers. (A timer can be triggered through an EJB timer, the timer service, or the scheduler.) This limit is low by default because each timer is expected to be of short duration. When the number of timers is at the limit, such as if timers are running longer for any reason, timers are no longer executed. When a new timer occurs, OC4J logs a warning message.

Solution

To work around this problem, you can use either of two OC4J system properties:

  • timer.service.debug

    This property determines whether to log additional diagnostic information for the timer service, including information about the current number of running timers. For example:

    -Dtimer.service.debug=true

  • executor.concurrent.tasks

    This property specifies the number of concurrent tasks for the Executor Service. Through this property you can increase the maximum number of concurrent timers allowed by OC4J. For example:

    -Dexecutor.concurrent.tasks=12

Note:

Each timer executes in a separate thread. If the maximum number of timers is set too high, resulting in numerous timers executing, then OC4J uses many threads. Oracle recommends that you recycle threads once they finish executing.

For information about setting system properties, see Chapter 4, "OC4J Runtime Configuration."

java.lang.OutOfMemory Errors

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 your application is running in an OPMN-managed environment, these JVM settings are defined within a <data id="java-options"> element in the opmn.xml configuration file. For example:

<ias-component id="default_group">
  <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 your application is running in a Linux or UNIX environment, verify that ulimit settings allow the JVM process to allocate this much memory.

Application Performance Impacted by Garbage Collection Pauses

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.

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/

Invalid or Unneeded Library Elements Degrading Performance

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.

ClassCastExceptions and ClassNotFound Errors

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 issues related to class loading. It also explains how you can use shared libraries to avoid many of these issues within OC4J.

OC4J Fails to Start: Unable to Find Java Compiler

Problem

An error similar to the following one 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

Error When Clustering an Application

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.

Error When Downgrading from JDK 5.0 to JDK 1.4.2

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 newer 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:

  1. Stop the OC4J instance.

  2. Delete the ORACLE_HOME/j2ee/instance/application-deployments directory.

    Deleting this directory will cause the application files to be recompiled when OC4J is restarted with the JDK 1.4.2.

You can specify the JDK to use for each OC4J instance through manual edits to the opmn.xml configuration file. If you want to use the javac compiler installed with the JDK defined in the JAVA_HOME environment variable, also remove the <java-compiler> element from server.xml and let OC4J rediscover the default settings.

Unsupported Methods in JMX MBeanServer and MBeanServerConnection Interfaces

Problem

A number of methods from the JMX MBeanServer interface are not available to a J2EE application when it uses an MBeanServer object obtained from the following operation:

MBeanServer mbsrv = MBeanServerFactory.newMBeanServer();

The use of any of the following methods on the returned MBeanServer object will throw an UnsupportedOperationException exception:

public final ClassLoader getClassLoaderFor(ObjectName mbeanName)

public final ClassLoader getClassLoader(ObjectName loaderName)

public final ClassLoaderRepository getClassLoaderRepository()

public final Object instantiate(String className)

public final Object instantiate(String className, ObjectName loaderName)

public final Object instantiate(String className, Object[] params, String[] signature)

public final Object instantiate(String className, ObjectName loaderName, Object[] params, String[] signature)

public final ObjectInstance createMBean(String className, ObjectName name)

public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loaderName)

public final ObjectInstance createMBean(String className, ObjectName name, Object[] params, String[] signature)

public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loader, Object[] params, String[] signature)

public final ObjectInputStream deserialize(ObjectName name, byte[] data)

public final ObjectInputStream deserialize(String className, byte[] data)

public final ObjectInputStream deserialize(String className, ObjectName loaderName, byte[] data)

A number of methods from the MBeanServerConnection interface are not supported when an application uses the Oracle JMX connectors. The use of any of the following methods on the MBeanServerConnection object that is created will throw an UnsupportedOperationException exception:

public final ObjectInstance createMBean(String className, ObjectName name)

public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loaderName)

public final ObjectInstance createMBean(String className, ObjectName name, Object[] params, String[] signature)

public final ObjectInstance createMBean(String className, ObjectName name, ObjectName loader, Object[] params, String[] signature)

Solution

If your application uses the JMX MBeanServer or MBeanServerConnection interface, avoid using any of the unsupported methods in the application.

OC4J Hanging When Starting Applications in Oracle Application Server

Problem

In an OPMN-managed environment, OPMN appears to hang while trying to start OC4J, resulting in an error similar to the following one:

ias-component/process-type/process-set: 
    default_group/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 timeout value to 800 seconds for applications deployed to the home OC4J instance:

<ias-component id="default_group">
  ...
  <process-type id="home" module-id="OC4J" status="enabled">
    ...
    <start timeout="800" retry="2"/>
  </process-type>
</ias-component>

Additional Help

You can search for additional solutions on the following Oracle support-oriented Web sites:

If you still cannot find a solution for the problem you are facing, please log a service request.

Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us