Web module or application server dies or hangs
If an application server dies (its process spontaneously closes), or freezes
(its Web modules stop responding to new requests):
- Isolate the problem by installing Web modules on different servers, if
possible.
- As an alternative to
using the performance viewer to detect
memory leak problems, enable verbose garbage collection on the application
server. This feature adds detailed statements to the JVM error log file of
the application server about the amount of available and in-use memory. To
set up verbose garbage collection:
- Select Servers > Application Servers > server_name > Process
Definition > Java Virtual Machine, and enable Verbose Garbage Collection.
- Stop and restart the application server.
Periodically, or after the application server stops, browse the log
file for garbage collection statements. Look for statements beginning with
"allocation failure". The string indicates that a need for memory allocation
has triggered a JVM garbage collection (freeing of unused memory). Allocation
failures themselves are normal and not necessarily indicative of a problem.
The allocation failure statement is followed by statements showing how many
bytes are needed and how many are allocated.
If there is a steady increase
in the total amount of free and used memory (the JVM keeps allocating more
memory for itself), or if the JVM becomes unable to allocate as much memory
as it needs (indicated by the bytes needed statement), there might be a memory
leak.
- If either the performance
viewer or verbose garbage collection output indicates that the application
server is running out of memory, one of the following problems might be present:
- If an application server
spontaneously dies, look for a Java thread dump file. The JVM creates the
file in the product directory structure, with a name like javacore[number].txt.
- Force an application to
create a thread dump (or javacore). Here is the process for forcing a thread
dump, which is different from the process in earlier releases of the product:
- Using the wsadmin command prompt, get a handle to the problem application
server: wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
- Generate the thread dump: wsadmin>$AdminControl invoke $jvm dumpThreads.
- Look for an output file in the installation root directory with a name
like javacore.date.time.id.txt.
- Browse the thread dump
for clues:
- If the JVM creates the thread dump as it closes (the thread dump is not
manually forced), there might be "error" or "exception information" strings
at the beginning of the file. These strings indicate the thread that caused
the application server to die.
- The thread dump contains a snapshot of each thread in the process, starting
in the section labeled "Full thread dump."
- Look for threads with a description that contains "state:R". Such threads
are active and running when the dump is forced, or the process exited.
- Look for multiple threads in the same Java application code source location.
Multiple threads from the same location might indicate a deadlock condition
(multiple threads waiting on a monitor) or an infinite loop, and help identify
the application code with the problem.
For current information available from IBM Support on known problems and
their resolution, see the IBM Support
page.
IBM Support has documents that can save you time gathering information
needed to resolve this problem. Before opening a PMR, see the IBM Support
page.

Troubleshooting by task: What are you trying to do?
Searchable topic ID:
rtrb_appdies
Last updated: Jun 21, 2007 4:12:58 PM CDT
WebSphere Application Server Express, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.exp.doc/info/exp/ae/rtrb_appdies.html