Miscellaneous Errors

OutOfMemoryError

These types of errors are typically caused by one of these issues:

Running out of threads

Many different types of threads are available; however, they fall into two categories: Java threads and native threads. All threads that are running within a Java™ virtual machine (JVM™) are Java threads ( java.lang.Thread class inside Java). The native code (C++/C) creates native threads that are scheduled and managed by the operating system. Here are the key differences between the two types:

Because the operating system has no visibility into Java threads, when you monitor threads by using operating system tools such as perfmon , you are monitoring only native threads. The only way to get details into Java threads is to get a Java thread dump . The process about how to get a Java thread dump varies, depending on your application server and JVM. Refer to the manufacturer's documentation.

Incidentally, the implementation of the JVM is done in C/C++ code and that JVM code maps Java threads to native threads. This mapping can be either 1:1 (1 Java thread to 1 native thread) or N:1 (multiple Java threads to 1 native thread). The details of how this mapping works will be specific to the JVM vendor; however, 1:1 mapping is a typical default. This means that each Java thread will have a corresponding native thread. The number of Java threads has no definite limit; however, because 1:1 mapping is typical and the number of native threads has definite limits, you can run out of Java threads as well. This limit applies per process (JVM being a single process) and varies on each operating system. You can assume that the limit will be in the thousands (but less than 10,000). Regardless of this number, having several hundreds of threads is a performance problem because the operating system has to schedule up to that many threads.

Threads and memory allocation

Another common issue for threads pertains to memory allocations. When a new Java thread is allocated, a fixed amount of memory is required for the thread's stack. This thread stack space is a tunable parameter ( -Xss option for JVM) and the default is ~512 KB . Therefore, if you have 1000 threads, 500 MB of memory will be required just for the thread's stacks. This memory will compete with all the other memory allocations being done in the JVM (for example, what LiveCycle ES3 allocates) and will create memory allocation issues.

In practice, when the JVM cannot allocate memory or create threads, it throws an OutOfMemory exception back to the caller. Along with this exception will be a stack trace and a reason for throwing the exception. This reason is very important to take notice of; it will give you further clues to what the problem may be.

The following code is an example of a message that displays two errors and their associated reason codes:

"unable to create new native thread: java.lang.OutOfMemoryError: unable to create new native thread java.lang.OutOfMemoryError: Java heap space"

These errors mean that the JVM could not create more threads for one of these reasons:

To determine the exact cause, you need to get a thread dump (also known as Java jump ). Thread dump will generally be called javacore.xxxx.txt and reside under an application server's log directories. Much information will be inside the thread dump, but you can quickly determine the number of threads by counting the occurrences of the TID: token on the list. A typical entry will look like this example:

"Thread-1227" (TID:0x106948F0, sys_thread_t:0x78996DA0, state:R, native ID:0x191C) prio=5
4XESTACKTRACE at java.net.SocketInputStream.socketRead0(Native Method)
4XESTACKTRACE at java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code))
4XESTACKTRACE at java.io.BufferedInputStream.fill(BufferedInputStream.java(Compiled Code))
4XESTACKTRACE at java.io.BufferedInputStream.read1(BufferedInputStream.java(Compiled Code))
4XESTACKTRACE at java.io.BufferedInputStream.read(BufferedInputStream.java(Compiled Code))
4XESTACKTRACE at com.sun.jndi.ldap.Connection.run(Connection.java(Compiled Code))
4XESTACKTRACE at java.lang.Thread.run(Thread.java:567)
If you find thousands of threads, you are probably running out of threads. Developers should be able to identify obvious culprits by scanning the stack traces of these threads.

Note: Thread dumps are typically intrusive and require that you restart the application server afterward.

If the thread count is in the hundreds, the reason for the java.lang.OutOfMemory error is not the thread limit. Reduce the thread stack size ( -Xss option mentioned above), rerun LiveCycle ES3, and check whether the problem disappears.

404 File not found

If you see this error, perform these checks:

Class not found

If you see this error, check whether any of these problems exist:

JNDI name not found

If the symptom is an exception stack trace showing javax.naming.NameNotFoundException: jdbc/<badName> , check whether the expected name is spelled correctly; if it is not, fix the code.

To correct most common JNDI exceptions, follow this process:

  1. Check the JNDI tree on the LiveCycle ES3 application server. Does the name used appear in the tree?
    • If yes, it is most likely that your code has not properly set up the InitialContext object being used for the look-up, and the look-up is being done on a JNDI tree that is not the one the resource is listed in. For the property values to use, see the Installing and Deploying LiveCycle ES3 document for your application server.
    • If no, continue to step 2.
  2. Check whether the resource appears in the JNDI tree under a name other than the name that is listed in the look-up?
    • If yes, you are using the incorrect look-up name. Provide the correct name.
    • If no, continue to step 3.
  3. Review the application server logs during startup. If the application server is configured to make this resource available but it is not working properly, an exception appears here. Did an exception appear?
    • If yes, review the exception and stack trace. If the NameNotFoundException is a symptom of another problem based on your investigation of the server logs, go to the troubleshooting steps for that problem.
    • If no, continue to step 4.
  4. If the resource is not listed in the JNDI tree and no exception appears at startup to explain why it is not available, the most probable issue is that the application server is not configured properly to make that resource available. Review the application server configuration. Is it configured to make this resource available?
    • If no, refer to the Installing and Deploying LiveCycle ES3 document for your application server.
    • If yes, this problem is not one of the common ones that cause this issue. Contact Adobe Support.