Clarify @Asynchronous @Retry @Bulkhead

When using the thread pool approach, when a request cannot be added to the waiting queue, BulkheadException will be thrown.

However, if @Retry is also used, it might not be possible to throw the BulkheadException immediately. E.g. in the following example, if the first invocation fails due to some networking problem and the second invocation fails due to bulkhead, we cannot throw the BulkheadException when ping() completes from the client point of view. The only thing we can do is to “throw” the BulkheadException via Future.get() and ExecutionException.

    @Asynchronous
    @Bulkhead(value = 5)
    @Retry(maxRetry = 4)
    public Future<String> ping() {
        // do some networking... 
        return CompletableFuture.completedFuture("ok");
    }

[Emily-Jiang]

As for today’s hangout, the current proposal is:

If @Bulkhead used with @Async and @Retry, when BulkheadException occurs, which will trigger the Retry, the execution of Retry will happen on the calling thread.

[OndroMih]

I agree with @mkouba - asynchronous methods should return asynchronous result and also throw exceptions asynchronously. An exception is an alternative return type and should behave as the normal return type unless there are specific needs to throw them directly.

The spec now says:

The @Asynchronous annotation can be used together with @Timeout, @Fallback, @Bulkhead and @Retry. Method invocation will occur in a different thread.

I would change this to “Method invocation and all the 4 FT interceptors will occur in a different thread”.

That would imply that @Bulkhead also happens on another thread and hence doesn’t throw an exception but finish the future with an exception.

This would make even more sense when we add CompletionStage support, where an exception handler would be called in a separate thread.