Failure Analysis of Open Source J2EE Application Servers

Simulation-based analysis of middleware service impact on system reliability: Experiment on Java application server

“…Assuming that the reliability of all services is the same -80%, i.e., 20 out of 100 invocations failed due to faults injected to a given service. Both durative mode and random mode are tested but, here, we only show the random mode because it reflects the real case better according to our findings in bug repository analysis of JEE application servers [29]. In Figure 10-14, the x-axis identifies the use cases of JPS or ECperf and the y-axis is the failed request ratio when injecting faults into the given service.…”

“…Consequently, most of the faults coming from the underlying, middleware and application levels can be captured by exceptions. After analyzing the bug repository of some open source JEE application servers, we find that more than 70% middleware failures are manifested by exceptions [29]. Moreover, there are two advantages of manifesting faults as exceptions on evaluating service impacts on reliability of distributed system: one is both software faults and operator mistakes are the main causes of failures in distributed systems [17]; another is exceptions can be simulated and controlled in a fine-grained, easy and precise manner.…”

Self-healing strategies for component integration faults

“…A recent field study of 32 Java and .NET applications shows that the amount of code used in error handling is much less than expected (only 3-7% for Java, 3% for .NET) [4]. Moreover, when exception handlers exist, they usually execute general actions (e.g., exception propagation, graceful degradation and termination) which are likely to cause systems to misbehave, disrupt their services or crash, e.g., 12-16% of the 70% failures reported in [18] appear to be caused by poor exception handling.…”

“…For example, a recent study on 3 widely-used J2EE application servers (Geronimo, JBoss AS and JOnAS) reports that 70% of the failures are manifested by exceptions [18].…”

Using Runtime Information and Maintenance Knowledge to Assist Failure Diagnosis, Detection and Recovery

“…This approach is less polluting to the software logic and its architecture, since it formalizes the communication between the module that identifies the failure and the one that will handle it. However, this approach still does not reach the expected result, since 70% of the failures are manifested by exceptions, mainly because it is difficult to write an exception handler that correctly recovers the failure signaled by the exception (Li et al, 2007).…”