Troubleshooting

Latest revision as of 15:31, 21 February 2006

For a complete list of all troubleshooting topics, see Category:Troubleshooting

Resin stops responding

• There may be a thread deadlock problem, obtain a thread dump.

• Enable debug logging and check the last log entries for hints about what the last thing to happen was.

Resin keeps restarting

• Enable debug logging and check the entries for an explanation of why Resin thinks it should restart.

No line numbers in exception stack traces

• In resin.conf specify -g as an option for Resin to pass to the java compiler:

 <java compiler='javac' compiler-args='-g'/>

• Specify -nojit as a command-line option when starting Resin:

win> bin/httpd.exe -nojit
unix> bin/httpd.sh -nojit

java.lang.OutOfMemoryError exception, application runs out of memory

Main article: OutOfMemoryError

• Use JVM memory options to increase heap memory.
• Obtain a heap dump to determine which objects are not getting garbage collected.
• Obtain a thread dump and check for unreleased threads that might be holding onto objects.

An OutOfMemoryError exception is usually an indication that heap memory is being used up. Often this is from application code keeping references to objects that are no longer needed, and the garbage collector does not free them. A heap dump can help determine which code and which kinds of objects are being held.

If the heap dump or other monitoring tools reveal that the server and your appliciation(s) actually are not running out of heap memory then an OutOfMemoryError indicates that then the JVM is running out of virtual memory, i.e. an underlying malloc() call is failing.

Often this situation is indicated by using OS tools to show memory usage, the JVM itself indicates it has heap memory but the OS tool shows that the process is using a very large amount of memory. On Windows the task manager is used, on Unix top or ps.

After a while the server starts to go very slow

• This may be a garbage collection issue.
  • Monitor garbage collection with -verbosegc.
  • If the JVM is running out of memory, then the JVM will slowly halt (and continually GC) until it dies, indicated by frequent full garbage collections.
  • If the JVM heap is swapped out to disk by the operating system, then when a full garbage colleciton occurs all of the JVM heap must be swapped back into memory as the garbage collector examines all of the memory. Indicated by very long full garbage collection times.
  • If you have a memory leak, then an excessive number of objects may get created, causing the garbage collector to use up all of your CPU.
    • Obtain a heap dump to determine if objects are not getting garbage collected.
• This may be a runaway thread or a request that is tying up resources. If a thread does not return from a request, Resin will not be able to reuse the thread and will have less threads to service new requests. Use resin-status to determine the number of active connections and obtain a thread dump and check for unreleased threads that might be holding onto objects.

CPU spikes, excessive CPU usage

• Obtain a thread dump and check for threads that are caught in tight loops.
• Check for garbage collection issues.

Sessions become null, losing session

See Losing session.

Specification version 1.3 of package javax.servlet, J2EE Specification, version 1.3 is not compatible with Resin

See Clean up the classpath

Unsupported major.minor version 48.0

This error usually happens when a conflicting jar is found, see Clean up the classpath.

If the classpath is completely cleaned up, as suggested in the link, then a jar or some other component of a jdk installation or older Resin installation is coming from somewhere else.

There may be a problem with some jar in your JAVA_HOME tree, if you have added anything there. There may be a conflicting jar in WEB-INF/lib/ of your webapp.

Another possibility is that you have not set JAVA_HOME, or if you have then some component of a conflicting jdk installation (javac for example, or the java executable itself) is getting used.

If on windows, check for stray copies of java.exe outside of JAVA_HOME, for example in C:\WINDOWS\java.exe or anywhere else in your PATH.