Chain of onFailure().withBackOff() may break CompletableFuture invocation about smallrye-mutiny HOT 6 CLOSED

To provide a simplified reproducer:

///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS io.smallrye.reactive:mutiny:2.5.1

import java.time.Duration;
import java.util.concurrent.atomic.AtomicBoolean;

import io.smallrye.mutiny.Uni;

public class MutinyBackoff {

    public static void main(String[] args) throws Exception {
        AtomicBoolean test = new AtomicBoolean(false);
        Uni.createFrom().item(() -> {
            if (test.getAndSet(true)) {
                return new Object();
            }
            throw new RuntimeException("BOOM!");
        })
                .log("retry")
                .onFailure().retry()
                .withBackOff(Duration.ofMillis(100), Duration.ofSeconds(5)) // If we comment this line the thread is not interrupted
                .atMost(1)
                .log("invoke")
                .onItem().invoke(c -> {
                    if (Thread.currentThread().isInterrupted()) {
                        System.out.println("isInterrupted !!!! " + Thread.currentThread().getName());
                    }
                })
                .log("await")
                .await()
                .atMost(Duration.ofSeconds(1));
    }

}

The output of this is:

[jbang] Building jar for MutinyBackoff.java...
[--> invoke.0 | onSubscribe()
[--> await.0 | onSubscribe()
[--> retry.0 | onSubscribe()
[--> retry.0 | onFailure(java.lang.RuntimeException("BOOM!"))
[--> retry.1 | onSubscribe()
[--> retry.1 | onItem(java.lang.Object@fbba27b)
[--> invoke.0 | onItem(java.lang.Object@fbba27b)
isInterrupted !!!! pool-1-thread-1
[--> await.0 | onItem(java.lang.Object@fbba27b)

When using the withBackOff the following calls to onItem() have the Thread interrupted, this causes conflicts with CompletableFuture since the CompletableFuture fails with java.lang.InterruptedException.

Trying to set as a workaround a .onItem().invoke(c -> Thread.interrupted()) after .atMost(1) could be possible but we need to ensure that this might now introduce any other undesired effect.

On versions < 2.0.0 (like 1.10.0) this behavior doesn't occur, this is breaking the upgrade of Quarkus/Mutiny so any help is appreciated.

from smallrye-mutiny.

I confirm that there is a (subtle!) issue here, PR coming

from smallrye-mutiny.

The default executor (outside Quarkus) is a created from Executors.newCachedThreadPool() so there's a (default) keep-alive delay and non-daemon threads. If you wait long enough the program shall terminate.

from smallrye-mutiny.

Thanks I will have a look

from smallrye-mutiny.

I guess what you are observing is related to 46553d0

I think it's a consistent way to handle InterruptedException just like you would do in imperative programming, as we need to 1/ forward the exception downstream, and 2/ since it's an InterruptedException and it has special meaning the interrupt flag shall be set.

Now I'm looking at why a thread is being interrupted by the backoff code, and if that's a correct behaviour or not.

from smallrye-mutiny.

Thanks @jponge for the quick response, on a side note (not sure if we need to open a different issue), if mutiny uses a different executor (emitOn or runSubscriptionOn) even on this simple program:

public class FirstProgram {
  public static void main(String... args) throws Exception {
    Uni.createFrom().item("hello")
        // .emitOn(Infrastructure.getDefaultExecutor())
        .runSubscriptionOn(Infrastructure.getDefaultExecutor())
        .onItem().transform(item -> item + " mutiny")
        .onItem().transform(String::toUpperCase)
        .subscribe().with(item -> System.out.println(">> " + item));
  }
}

The program never exits, but the main thread dies, yet it looks like it starts a DestroyJavaVM thread and the program never ends., since the backoff feature uses an executor internally it also has this issue, and when the backoff kicks in, the program never ends, not sure if this is an issue or is just a wrong understanding of how this should work.

from smallrye-mutiny.