add fail fast policy

[Ladicek]

Currently, we have @CircuitBreaker, which automatically (based on relatively simple criteria) provides a "fail fast" behavior. I propose to add general @FailFast policy, which would delegate the "should fail fast?" decision to some handler. For example:

public class MyService {
    @FailFast(MyServiceFailFastHandler.class)
    public void someCostlyMethod() {
        ...
    }
}

public class MyServiceFailFastHandler implements FailFastHandler {
    public boolean shouldFailFast(FailFastContext ctx) {
        ...
    }
}

The API would look something like this:

public @interface FailFast {
    Class<? extends FailFastHandler> value();
}

public interface FailFastHandler {
    boolean shouldFailFast(FailFastContext ctx);
}

// similar to existing `ExecutionContext`
//
// we could also use `ExecutionContext` unmodified,
// and specify that `getFailure` is always `null` (or throws an exception)
public interface FailFastContext {
    Method getMethod();
    Object[] getParameters();
}

// thrown when `FailFastHandler.shouldFailFast` returns `true`
public class FailFastException extends FaultToleranceException {
}

I didn't have much time to look into this yet, so I'm filing this issue just to gather some feedback.

[michalszynkiewicz]

Would getFailure method be added to the FailFastContext?
Do we want to pass/provide some means to pass some context between @FailFast invocations?

[Ladicek]

I don't see a FailFastContext.getFailure method. But I found that there's one thing missing in my API proposal -- an exception that gets thrown in case FailFastHandler returns true. I'll edit the proposal.

I personally envision fail fast as completely stateless. Perhaps the FailFastContext could be made CDI-managed, which would accomodate state. I think this is similar to FallbackHandler, for which we say this:

FallbackHandlers are meant to be CDI managed, and should follow the life cycle of the scope of the bean.

I'm not sure I understand what that means, but we could say the same about FailFastHandler.

[Ladicek]

Also, similarly to @Fallback, we could have two options: a handler class (@FailFast(MyFailFastHandler.class)) and a handler method (@FailFast(failFastMethod = "myFailFastMethod")). The handler method would be resolved similarly to fallback, except it would always have to have a return type of boolean.

[michalszynkiewicz]

In other words, one would be able to inject CDI beans into the handler? That should be enough to be able to do something sensible.

WDYT about naming it @FailWhen instead of @FailFast? And then the class could be called FailCheck and the property to specify the method could be something along the lines of failCheckMethod or checkMethod.
IMO it would indicate more clearly what the annotation does.

[Ladicek]

I went with "fail fast" as that's how Release It calls it :-)

[Emily-Jiang]

@Ladicek will experiment in SmallRye first and comes back with more findings.