Skip Headers

Oracle® Containers for J2EE Deployment Guide 10g Release 3 (10.1.3) Part No. B14431-01 |
| Home | Solution Area | Contents | Index

Previous | Next |

# 15 Troubleshooting Deployment Errors

This chapter discusses common errors that may occur during deployment. It includes the following sections:

- Interruptions During Application Deployment

- Exceptions During Application Deployment

## Interruptions During Application Deployment

If the deployment process is interrupted for any reason, you may need to clean up the temp directory, which by default is `/var/tmp`, on your system.

The Application Server Control Console deployment wizard uses approximately 20 MB in swap space of the temp directory for storing information during the deployment process. At completion, the deployment wizard cleans up the temp directory of its additional files.

However, if the wizard is interrupted, it may not have the time or opportunity to clean up the temp directory. Thus, you must clean up any additional deployment files from this directory yourself. Otherwise, this directory may fill up, which will disable any further deployment.

You can change the temp directory at OC4J startup by setting the `java.io.tmpdir` command-line option to a new location. See the Oracle Containers for J2EE Configuration and Administration Guide for details on setting system properties.

## Exceptions During Application Deployment

This section provides details on the following types of errors that may occur during deployment:

- OC4J Out of Memory Errors

- Java Compiler Out of Memory Errors

- Stack Overflow Errors

- "Too many open files" Errors

### OC4J Out of Memory Errors

Deploying a large EAR file - such as a file larger than 75 MB - may cause OC4J to throw `java.lang.OutOfMemory` errors. If sufficient memory is available, you can eliminate this problem by increasing the heap size for the OC4J process at OC4J startup. For example:

    java -Xms512m -Xmx512m -jar oc4j.jar

This problem may also be encountered when deploying an application using the `admin.jar` command-line utility. Again, the solution is to increase the heap size for this utility:

    java -Xms512m -Xmx512m -jar admin.jar ormi://localhost:23791 admin welcome -deploy ...

If running under Unix/Linux, verify that the `ulimit` settings allow the JVM process to allocate this much memory.

### Java Compiler Out of Memory Errors

OC4J may return the following message when using the `javac` compiler in out-of-process mode when compiling EJB wrapper classes:

    The system is out of resources.
    Consult the following stack trace for details.
    java.lang.OutOfMemoryError: Java heap space

This message indicates that the external JVM process spawned to execute the `javac` compiler has run out of memory.

The default heap size allocated to the compiler is 1024 MB. To allocate more memory to the compiler, increase the heap size by setting the `-Xmx` option through the `options` attribute of the `<java-compiler>` element in `server.xml`. For example:

    <java-compiler name="javac" in-process="false" options="-J-Xmx2048m"/>

### Stack Overflow Errors

The `javac` compiler may throw a `java.lang.StackOverflowError` when compiling EJB wrapper classes if your application is too large.

The thread stack size option enables the control of the `stacksize` attribute of a thread attributes object. This attribute specifies the minimum stack size to be used for the created thread.

If this occurs, you can increase the thread stack size by setting the -`Xss` option through the `options` attribute of the `<java-compiler>` element in `server.xml`. For example:

    <java-compiler name="javac" in-process="false" options="-J-Xmx2048m -J-Xss=8m"/>

### "Too many open files" Errors

When deploying large applications, the OC4J JVM may throw "too many open files" exceptions. For example:

    java.net.SocketException: Too many open files
    java.io.IOException: Too many open files

These exceptions indicate that the operating system has run short of file descriptors, which are used by processes to identify open files of different types, including sockets or pipes.

Increasing the number of file descriptors will typically resolve this kind of problem. On Unix platforms, this can be performed using the `ulimit -n` command. The maximum number of file descriptors, as well as the maximum size that can be allocated to a process, are defined by a resource limit. Refer to your operating system-specific system administration manuals for instructions on setting the hard limit values.