Analyzing application failures

Application failures can be caused by a number of coding problems, each of which you will want to investigate using the data collection and analysis techniques and tools available to you. Typical application failures include crashes, where the application unexpectedly terminates, and hangs, where the application becomes unresponsive as it, for example, enters an infinite loop or waits for an even that will never happen.

Tracking such problems can involve trial-and-error as you collect and analyze data in various ways. You may find your own way that works best. Try the following steps:

  1. Import the application's log files into the Log and Trace Analyzer.
  2. Correlate them and examine them for high-severity records. For more information, see Analyzing log files.
  3. Next, if you have not found the source of the problem, collect performance data. See Collecting realtime performance data. When you create a new profiling configuration (see Creating a profiling configuration for run-time problem determination), select the J2EE Performance Analysis profiling set on the Overview tab of the Profiling page.
  4. Correlate and analyze the data with a Host, Process, or Thread interaction diagram, or other advanced profiling tools to determine the specific problematic machine, process or thread.
  5. Next, if you have not found the source of the problem, collect memory-level data from on the troublesome machine, process or thread identified in the previous step. See Collecting realtime performance data. When you create a new profiling configuration (see Creating a profiling configuration for run-time problem determination), select the Memory Analysis or one of the other memory-related analysis sets on the Overview tab of the Profiling page.
  6. Analyze with the profiling tools for identifying thread bottlenecks (See Identifying thread bottlenecks).
  7. In the case of a hang, you might not see any actual errors logged. Use interaction diagrams, statistical views, and thread analysis tools to find the problem. For example, if the problem is an endless loop, the UML2 sequence diagrams will show you repeating sequences of calls, and statistical tables will show methods that take a long time. If the problem is a deadlock, thread analysis tools will show that threads you expect to be working are actually waiting for something that is never going to happen.
Terms of use | Feedback
(C) Copyright IBM Corporation 2005. All Rights Reserved.