If an application server process spontaneously closes,
or Web modules stop responding to new requests, it is important that
you quickly determine why this stoppage is occurring. You can use
some of the following techniques to determine whether the problem
is a Web module problem or an application server environment problem.
If an application server process spontaneously closes, or Web modules
running on the application server stop responding to new requests:
- Try to Isolate the problem by installing the Web modules on different
servers, if possible.
- Use the Tivoli performance viewer to determine if any of the application
server resources, such as the Java heap, or database connections,
have reached their maximum capacity. If there is a resource problem,
review the application code for a possible cause:
- If database connections are being assigned to a request but are
not being released when the requests finish processing, ensure that
the application code performs a close() on any opened Connection object
within a finally{} block.
- If there is a steady increase in servlet engine threads in use,
review application synchronized code blocks for possible deadlock
conditions.
- If there is a steady increase in a JVM heap size, review application
code for memory leak opportunities, such as static (class-level) collections,
that can cause objects to never get garbage-collected.
- Enable verbose garbage collection on the application server to
help you determine if you have a memory leak problems. This feature
adds detailed statements about the amount of available and in-use
memory to the JVM error log file.
To enable up verbose garbage
collection:
- In the administrative console, click Servers
> Application Servers > server_name. . Then, under Server
Infrastructure, click Java and Process Management > Process Definition
> Java Virtual Machine, and enable Verbose Garbage Collection.
- Stop and restart the application server.
- Periodically, browse the log file for garbage collection statements.
Look for statements beginning with "allocation failure". This string
indicates that a need for memory allocation has triggered a JVM garbage
collection, to release unused memory. Allocation failures are normal
and do not necessarily indicate a problem. However, the statements
that follow the allocation failure statement show how many bytes are
needed and how many are allocated. If these bytes needed statements
indicate that the JVM keeps allocating more memory for its own use,
or that the JVM is unable to allocate as much memory as it needs,
there might be a memory leak.
You can also use the Tivoli performance
viewer to detect memory leak problems.
- Browse the thread dump for clues:
The
JVM creates a thread dump whenever an application server process spontaneously
closes. You can also force an application to create a thread dump.
After a dump is created, you can check the dump for clues as to why
new requests are not being processed.
To force a thread dump:
- Using the wsadmin command prompt, get a handle to the problem
application server:
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server_name,*]
where server_name is
the name of your server.
- Generate the thread dump:
wsadmin>$AdminControl invoke $jvm dumpThreads
Note: The
dumpThreads command creates other types of dump files depending on
the -Xdumps settings. Dump output varies depending on the platform
and might include system core files, heap, and snap dumps.
- Look for an output file in the profile_root/logs directory
with a name like javacore.jobnum.jobuser.jobname.timestamp.txt.
After the application creates the dump, you can check for
the following clues:
- Look for an excessive current heap size. The
thread dump shows information on the current Java heap size, and the
minimum and maximum heap size settings.
- Look at the snapshot of each thread in the
process. The thread dump contains a snapshot of each thread in the
process, starting in the section labeled "Thread Information."
IBM
® Support
has documents and tools that can save you time gathering information
needed to resolve problems as described in
Troubleshooting help from IBM. Before opening a problem report, see
the Support page: