Resilience Patterns

The previous lesson measured whether a call reached its target. This lesson treats that failure not as a single event but as a repeating pattern: when a target fails over and over, what should the calling side do — give up immediately, retry a few times, or cut off retrying entirely past some point? The concepts of circuit breaker and retry patterns were built in the Resilience and Reliability course and are not repeated here; this lesson measures only how these patterns are added by an annotation and what they leave in the source. No real duration is written — what is measured is the attempt count and the threshold, both plain integers. This is the closing lesson of the course and of the M08 curriculum.

Resilience Added by Annotation: Attempt Count and Threshold

FragileService is a target manufactured to fail every time it is called; it carries two annotations — @Retry(count = 3) and @CircuitBreaker(threshold = 5). The party that reads and applies these two marks is not FragileService itself, but the ResilienceProxy wrapping it.

// Retry.java — annotation type stating how many times a target should be retried (helper source, no main)
import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE)
@interface Retry { int count(); }

// CircuitBreaker.java — annotation type stating after how many consecutive failures the circuit should open (helper source, no main)
import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE)
@interface CircuitBreaker { int threshold(); }

// OutsideService.java — interface for the called target (helper source, no main)
interface OutsideService { String call(); }

// FragileService.java — target manufactured to fail every time it is called (helper source, no main)
@Retry(count = 3) @CircuitBreaker(threshold = 5)
class FragileService implements OutsideService {
    int callCounter = 0;

    public String call() {
        callCounter++;
        throw new RuntimeException("target failed");
    }

    String otherOperation() {
        // calls directly from within itself, never seeing the proxy at all
        return call();
    }
}

// ResilienceProxy.java — proxy that reads the annotations and applies the retry and circuit breaker behavior (helper source, no main)
class ResilienceProxy implements OutsideService {
    final OutsideService target;
    final int retryCount;
    final int threshold;
    int consecutiveFailures = 0;
    boolean circuitOpen = false;
    int realCallCounter = 0;

    ResilienceProxy(OutsideService target) {
        this.target = target;
        Class<?> type = target.getClass();
        Retry r = type.getAnnotation(Retry.class);
        CircuitBreaker cb = type.getAnnotation(CircuitBreaker.class);
        this.retryCount = r != null ? r.count() : 1;
        this.threshold = cb != null ? cb.threshold() : Integer.MAX_VALUE;
    }

    public String call() {
        if (circuitOpen) {
            throw new IllegalStateException("circuit open, target was never reached at all");
        }
        RuntimeException lastError = null;
        for (int i = 1; i <= retryCount; i++) {
            realCallCounter++;
            try {
                String result = target.call();
                consecutiveFailures = 0;
                return result;
            } catch (RuntimeException e) {
                lastError = e;
                consecutiveFailures++;
                if (consecutiveFailures >= threshold) { circuitOpen = true; break; }
            }
        }
        throw lastError;
    }
}

// Measurement.java — result-printing helper (helper source, no main)
class Measurement {
    static void show(String label, Object value) {
        System.out.printf("%-52s: %s%n", label, value);
    }
}

The body of FragileService.call contains neither an attempt counter nor a threshold comparison; both live on the ResilienceProxy side. The same proxy.call() line is called three times in a row.

// AttemptsAndThreshold.java — the same call line reveals, in a manufactured continuous failure, the real attempt count and the threshold at which the circuit opens
public class AttemptsAndThreshold {
    public static void main(String[] args) {
        ResilienceProxy proxy = new ResilienceProxy(new FragileService());

        attempt(proxy, "call 1");
        attempt(proxy, "call 2");
        attempt(proxy, "call 3");

        Measurement.show("total number of real attempts (reaching the target)", proxy.realCallCounter);
        Measurement.show("is the circuit open", proxy.circuitOpen);
    }

    static void attempt(ResilienceProxy proxy, String label) {
        try {
            proxy.call();
            Measurement.show(label, "successful");
        } catch (Exception e) {
            Measurement.show(label, e.getMessage());
        }
    }
}

call 1                                              : target failed
call 2                                              : target failed
call 3                                              : circuit open, target was never reached at all
total number of real attempts (reaching the target) : 5
is the circuit open                                 : true

ST32. Circuit breaker and retry are added by an annotation; the proxy.call() call site never changes at all across the three attempt calls, the only thing determining the behavior is the two marks on FragileService. ST33. In a manufactured continuous failure, the real attempt count and the threshold at which the circuit opens are both numbers: the first call makes three attempts (count = 3), and because it has not yet reached the threshold (threshold = 5), the circuit stays closed; the second call makes two more attempts, and the moment consecutive failures reach five, the circuit opens — the total real attempt count is exactly 5. ST34. The third call, after the circuit has opened, is rejected without ever reaching the target; realCallCounter is still 5 after the third call, it does not increase.

The Limiting Measurement: A Call Not Passing Through the Proxy Stays Unprotected

FragileService has a second method that calls call from within itself: otherOperation. This call never passes through ResilienceProxy at all — the object calls its own method directly.

// UnprotectedCall.java — otherOperation() calls call() directly from within itself, the proxy is never involved, and no retry happens at all
public class UnprotectedCall {
    public static void main(String[] args) {
        FragileService inner = new FragileService();
        try {
            inner.otherOperation();
        } catch (RuntimeException e) {
            Measurement.show("result of the otherOperation() call", e.getMessage());
        }
        Measurement.show("direct call made from within otherOperation, how many attempts were made", inner.callCounter);
    }
}

result of the otherOperation() call                 : target failed
direct call made from within otherOperation, how many attempts were made: 1

inner.callCounter increases only once, not three times. ST35. The annotation applies only to a call passing through the proxy; a call the same class makes from within itself stays unprotected, because the party reading the @Retry and @CircuitBreaker marks is ResilienceProxy, and otherOperation never calls it at all. This is the same boundary measured by web-and-data-layer/06 — a component calling itself skipped the proxy there too — appearing here with a different outcome: there, a wrapped transaction boundary never opened at all; here, a wrapped resilience pattern never applies at all. Someone reading the source might assume otherOperation carries the same protection, because it calls the same class’s same call method; there is no mark in the source at all to disprove that assumption.

Summary

• Circuit breaker and retry are added by an annotation; the call site never changes at all.
• In a manufactured continuous failure, the real attempt count and the threshold at which the circuit opens are measured as numbers, neither of them a duration.
• Calls made after the circuit opens are rejected without ever reaching the target.
• The annotation applies only to a call passing through the proxy; a call the same class makes from within itself stays unprotected.
• This boundary is the same as the self-calling boundary measured by web-and-data-layer/06, with a different outcome.

Course Wrap-Up

The course opened with a single question: most of the code in a program using an application framework is never called by anyone at all, because the expression that constructs an object, the assignment that supplies a dependency, the line that calls a setup routine are, in their place, only annotations. Nineteen lessons asked this question across three topics — core concepts, the web and data layer, and security and distributed setup — and each time returned to the same triad: did a call give rise to this behavior in the source, an annotation, or neither.

The table’s third column confirms a single pattern: in five of the nineteen lessons the behavior comes entirely from an annotation (advice wrapping, four endpoints, column binding, the transaction boundary, the resilience patterns), in three it comes entirely or mostly from a default, and in the rest all three appear together. The limiting measurement column carries another pattern: in nearly all nineteen lessons the defect is silent — only two raise an error at all (the unbound interface, the capacity limit), the rest either return an unexpected value or carry on as if nothing changed. Someone reading the source top to bottom cannot see most of the behavior these nineteen lessons show, and cannot see that what they cannot see is broken either.

The M08 Java curriculum’s six courses asked six separate questions, and none took the place of another. Java Fundamentals counted which step, unwritten in the source, the compiler adds to the class file. Object-Oriented Java separated which type gives a decision at run time. The Standard Library and Streams measured who gives a guarantee — the caller or the library. JVM, Concurrency and Performance tracked which thread carries out a step. Build, Testing and the Ecosystem counted which type must be present on which class path and showed the difference between that and the run. This course, The Enterprise Application Framework, asked the sixth and final question: what gives rise to a behavior in the source — a call, an annotation, or neither. All six questions look at the same source text, but each searches for a different gap; none is a generalization of another, and none claims that reading the source top to bottom is enough.

M08 closes here. The source text tells only part of what a Java program does — the step it adds, the type that gives the decision, the party that gives the guarantee, the thread that carries it out, the required class path, the source of the behavior; all six are at least partly hidden from the eyes of someone reading the source, and all six become visible only by being run and counted.