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.
- If an application server's process spontaneously
closes, there will be an SDUMP for you to analyze.
- 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 >
Server Types > Application Servers > server_name. Then,
in the Server Infrastructure section, click Java and process management >
Process definition > Control > Java virtual machine, and
select 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.
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: