Exception handlers for healing component-based systems

Abstract

To design effective exception handlers, developers must predict at design time the exceptional events that may occur at runtime, and must implement the corresponding handlers on the basis of their predictions. Designing exception handlers for component-based software systems is particularly difficult because the information required to build handlers is distributed between component and application developers. Component developers know the internal details of the components but ignore the applications, while application developers own the applications but cannot access the details required to implement handlers in components.This article addresses the problem of automatically healing the infield failures that are caused by faulty integration of OTS components. In the article, we propose a technique and a methodology to decouple the tasks of component and application developers, who will be able to share information asynchronously and independently, and communicate implicitly by developing and deploying what we call healing connectors. Component developers implement healing connectors on the basis of information about the integration problems frequently experienced by application developers. Application developers easily and safely install healing connectors in their applications without knowing the internal details of the connectors. Healing connectors heal failures activated by exceptions raised in the OTS components actually deployed in the system.The article defines healing connectors, introduces a methodology to develop and deploy healing connectors, and presents several case studies that indicate that healing connectors are effective, reusable and efficient.

Process-Oriented Non-intrusive Recovery for Sporadic Operations on Cloud

“…In particular, for cases where successfully achieved conditions in previous steps are violated at later steps, non-intrusive recovery is able to handle them. For example, in step 2 of the rolling upgrade operation, if the resource generated in step 1 (Launch Configuration) is erroneous or was modified unexpectedly (e.g., the Launch Configuration was changed by another team) but was initially provisioned successfully, this error cannot be easily detected and handled by existing intrusive recovery mechanisms such as exception handling [17].…”

“… 17. shows the average recovery time of the two recovery strategies for each recovery point in the installation operation.…”

Automatic Workarounds

“…Exception handlers are usually very much application specific. However, several techniques extend basic exception handling mechanisms towards general handler that can work for multiple applications [Cabral and Marques 2011;Chang et al 2013;Harmanci et al 2011]. A similar approach, whereby a rule-based response mechanisms encodes alternative operations executed in response to a failure, has been applied to Web systems [Baresi and Guinea 2011;Modafferi et al 2006;Friedrich et al 2010].…”

Recovery for Failures in Rolling Upgrade on Clouds

“…There are several existing recovery mechanisms which can be used to recover from errors during rolling upgrade on cloud applications[13] [8] [22] [24]. For example, testdriven chef infrastructure [22] uses exception handlers to deal with failures during rolling upgrades.…”

“…It focuses on upgrading applications within a virtual machine rather than replacing the whole virtual machine which is the case for many upgrades. Cloud management software (such as Asgard [13] or OpenStack Omnibus[23]) use built-in exception handlers [24] to take recovery actions. The challenges of recovery through programming language exceptions handling is that it has limitations coping with cross-platform and cross-language exceptions [26], does not deal with time-delayed errors well and has no access to global information about the whole environment and other interfering operations.…”