First Failure Data Capture for your enterprise application with WebSphere Application Server

Since WebSphere Application Server version 7, we have exposed the First Failure Data Capture (FFDC) API to customer applications. Unfortunately we have not publicized this much in the Infocenter.

One of the key points for FFDC that differentiates it from log and trace is that it is a snapshot and not  history.  Log and Trace tends to give a narrow view, but a history that can be highly valuable.  FFDC tries to provide a wider view at a point in time. 

See Javadoc 
http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/ffdc/config/package-summary.html
http://publib.boulder.ibm.com/infocenter/wasinfo/fep/topic/com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/ffdc/package-summary.html

What is FFDC and Why do I care ?
FFDC is capturing the state of the application server and/or the application when an unexpected error or exception occurs the first time. All subsequent iterations of the same error/exception are ignored. This lightweight diagnostic collector of information is designed to be ALWAYS on in a production environment. WAS code leverages FFDC extensively to collect information and state for a component when an exception or catastrophic event occurs. You can now do the same for your enterprise application.

What differentiates it from logging ?

1. An exception has already occurred. This means that performance has been impacted and the code is in a failure path
2. FFDC is in the category of dump or snapshot type tools. These tools aim to provide a broad view of the system at a particular point in time. Logging keeps a narrow view, over a period of time
3. Each FFDC statement executes only once (some rare caveats). If the statement is executed again, it will know that it has already been executed, and it will simply update summary information. This means that FFDC processing can focus more on capturing all needed information, and less on performance.
4. The FFDC infrastructure provides many points where developers can plug in code that will be called when appropriate. The class or method experiencing a failure rarely knows all of the needed context to resolve the problem. FFDC provides extensions so that more focused serviceability code can take a more holistic view and gather a much broader context.

How do I use it ?

try { 

// Application code here 


} catch (Exception e) { 

    Ffdc.log(e, myClass, myClassName+myMethodName, “lineNumber”, cde1, cde2, …) ; 

}
// Args:  Exception, reporting class, “sourceId”, “probeId”, context data elements
// where sourceId and probeId are any strings, but this pattern is common 

package howto_ffdc._1_simple;
import static com.ibm.ffdc.Manager.Ffdc;
// import com.ibm.ffdc.Ffdc; // Used if alternate call is done below
public class SimpleTest extends TestCase {
 
   protected void setUp() throws Exception {
     System.setProperty("com.ibm.ffdc.log", “/opt/IBM/WebSphere/logs/ffdc/");
    }
    
    public void testWithoutFormatter(){
  try {
         // ... do work
  } catch (Exception e) {
         Ffdc.log(e, this, getClass().getName(),"24", customer);
         /* alternate if generating the parms for the call is expensive */
         // Ffdc ffdc = Ffdc.getFfdc(e, this, getClass().getName(),"24") ;
         //if (ffdc.isLoggable())
         //   MyData myData = expensiveCallToGetData() ;
         //   ffdc.log(customer, myData) ;
   }
 }
}

An excellent deep dive into FFDC by Michael Casile, WebSphere Serviceability Team Lead shows how you can use FFDC in your Java Enterprise application with WebSphere Application Server. http://slidesha.re/pWODOZ

In summary FFDC is a simple WebSphere application server facility to improve the serviceability of you enterprise software. It is low cost to implement, extensible, can grow with you (Data Collectors, Formatters, Providers, and Incident Forwarders) and the extensions do not impact core code i.e. no change needed to Ffdc.log statements to affect improved information.

... credits to Mike Casile and the WAS Serviceability team