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:
- Operating system tools (such as perfmon or Task Manager) knows only about native threads.
- Java threads are created and managed by LiveCycle ES3 code, application server, or the JVM itself.
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:
- The per-process thread limit is reached.
- The thread stack could not be allocated.
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:
- Confirm the problem in the browser's access log.
- Confirm that the EAR file deployed properly and that the application initialized.
- If the URL is intended for the HTTP server, check that the file exists. Look in the error_log file or error.log file for the full file name that the web server is looking for.
- (JBoss) Make sure the URL uses the correct case (it is case-sensitive).
- (JBoss) Check whether the web application context root (first part of the URL) exist in the uriworkermap.properties file of the JK plug-in configuration.
- (JBoss) If the file is a JSP, does the file exist in the EAR? This option will be confirmed by the absence of an entry in the HTTP server's error log file.
Class not found
If you see this error, check whether any of these problems exist:
- The class path setting is invalid or missing.
- The JAR file is obsolete.
- A compilation problem exists in the class.
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:
- 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.
- 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.
- 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.
- 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.