Web module or application server stops processing requests

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:

  1. 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.

  2. Stop and restart the application server.

  3. 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:

  1. Using the wsadmin command prompt, get a handle to the problem application server:

     wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*] 

  2. Generate the thread dump:

     wsadmin>$AdminControl invoke $jvm dumpThreads

  3. 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."

    • Look for threads that are waiting on locks held by other threads.

    • 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.

      It is normal for certain components in the WebSphere Application Server runtime to have certain types of threads in the same Java code source location. These components include the Web container, the EJB container and the ORB thread pool.

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:

• http://www.ibm.com/servers/eserver/support/iseries/allproducts/index.html

Related tasks

Reference topic