An adaptive failure detection protocol

Fetzer, Christof; Raynal, Michel; Tronel, Frédéric

doi:10.1109/prdc.2001.992691

Cited by 83 publications

(43 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For instance, recall that self-implementability of a failure detector in [17] depends critically on the query-based interface. Also, the so-called 'lazy' implementations of failure detectors [10] depend on a query-based interface to ensure communication efficiency; an analogous optimization is not known with a unilateral interface. Therefore, the significance and consequences of the interaction model merit investigation.…”

Section: Background and Motivationmentioning

confidence: 99%

Asynchronous failure detectors

Conrejo

Lynch

Sastry

2012

Proceedings of the 2012 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

Failure detectors -oracles that provide information about process crashes -are an important abstraction for crash tolerance in distributed systems. Although current failuredetector theory provides great generality and expressiveness, it also poses significant challenges in developing a robust hierarchy of failure detectors. We address some of these challenges by proposing a variant of failure detectors called asynchronous failure detectors and an associated modeling framework. Unlike the traditional failure-detector framework, our framework eschews real time completely. We show that asynchronous failure detectors are sufficiently expressive to include several popular failure detectors. Additionally, we show that asynchronous failure detectors satisfy many desirable properties: they are self-implementable, guarantee that stronger asynchronous failure detectors solve more problems, and ensure that their outputs encode no information other than process crashes. We introduce the notion of a failure detector being representative of a problem to capture the idea that some problems encode the same information about process crashes as their weakest failure detectors do. We show that a large class of problems, called finite problems, do not have representative failure detectors.

show abstract

Section: Background and Motivationmentioning

confidence: 99%

Asynchronous failure detectors

Conrejo

Lynch

Sastry

2012

Proceedings of the 2012 ACM Symposium on Principles of Distributed Computing

View full text Add to dashboard Cite

show abstract

“…While being conceptually fundamental, this strict separation of concerns does not necessarily result in more efficient implementations. Using application-level failure detection information, we can avoid sending failure detection messages when a stable leader exists [10]. Note that although some scoring function might require additional messages to calculate their θ scores, that is not the concern of the election algorithm itself.…”

Section: Related Workmentioning

confidence: 99%

Leader Election for Replicated Services Using Application Scores

2011

View full text Add to dashboard Cite

Abstract. Replicated services often rely on a leader to order client requests and broadcast state updates. In this work, we present POLE, a leader election algorithm that select leaders using application-specific scores. This flexibility given to the application enables the algorithm to tailor leader election according to metrics that are relevant in practical settings and that have been overlooked by existing approaches. Recovery time and request latency are examples of such metrics. To evaluate POLE, we use ZooKeeper, an open-source replicated service used for coordinating Web-scale applications. Our evaluation over realistic widearea settings shows that application scores can have a significant impact on performance, and that just optimizing the latency of consensus does not translate into lower latency for clients. An important conclusion from our results is that obtaining a general strategy that satisfies a wide range of requirements is difficult, which implies that configurability is indispensable for practical leader election.

show abstract

“…Thus, a process that does not need any information about failures simply stops its local IFD module. Second, intermittent failure detectors return only information about failures a process explicitly queried for, similarly to [9]. This enables frugal IFD implementations.…”

Section: Reducing the Cost Of Contention Managementmentioning

confidence: 99%

“…However, the way our contention managers obtain information about failures-from (intermittent) failure detectors-and the way they can be combined with heuristic contention management techniques are, we believe, novel. The implementations of IFDs I Ω * and I ♦P we give in this paper are similar to known message passing implementations of ♦P [1,7,9,25]. …”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

The weakest failure detectors to boost obstruction-freedom

2007

View full text Add to dashboard Cite

It is considered good practice in concurrent computing to devise shared object implementations that ensure a minimal obstruction-free progress property and delegate the task of boosting liveness to independent generic oracles called contention managers. This paper determines necessary and sufficient conditions to implement wait-free and non-blocking contention managers, i.e., contention managers that ensure wait-freedom (resp. non-blockingness) of any associated obstruction-free object implementation. The necessary conditions hold even when universal objects (like compare-and-swap) or random oracles are available in the implementation of the contention manager. On the other hand, the sufficient conditions assume only basic read/write objects, i.e., registers. We show that failure detector ♦P is the weakest to convert any obstruction-free algorithm into a wait-free one, and Ω * , a new failure detector which we introduce in this paper, and which is strictly weaker than ♦P but strictly stronger than Ω, is the weakest to convert any obstruction-free algorithm into a non-blocking one. We also address the issue of minimizing the overhead imposed by contention management in low contention scenarios. We propose two intermittent failure detectors I Ω * and I ♦P that are in a precise sense equivalent to, respectively, Ω * and ♦P, but allow for reducing the cost of failure detection in eventually synchronous systems when there is little contention. We present two contention managers: a non-blocking one and a wait-free one, that use, respectively, I Ω * and I ♦P . When there is no contention, the first induces very little overhead whereas the second induces some non-trivial overhead. We show that wait-free contention managers, unlike their nonblocking counterparts, impose an inherent non-trivial overhead even in contention-free executions.

show abstract

An adaptive failure detection protocol

Cited by 83 publications

References 14 publications

Asynchronous failure detectors

Asynchronous failure detectors

Leader Election for Replicated Services Using Application Scores

The weakest failure detectors to boost obstruction-freedom

Contact Info

Product

Resources

About