Multi.subscribe().asStream() slows down JVM termination

[lorenzpahl]

Using the asStream() operator to subscribe to a Multi causes the JVM to "hang" when the program terminates. The following program reproduces the problem:

///usr/bin/env jbang "$0" "$@" ; exit $?

//JAVA 23
//DEPS io.smallrye.reactive:mutiny:2.8.0

import io.smallrye.mutiny.Multi;

public class MutinyDemo {

    public static void main(String... args) {
        Multi.createFrom().range(1, 10)
                .subscribe().asStream().forEach(System.out::println);
                //.subscribe().asIterable().forEach(System.out::println);

        System.out.println("Stream processing completed.");
    }
}

The program prints the numbers 1 to 9 followed immediately by the text "Stream processing completed.", as expected. However, the program does not terminate right away. On my computer, it takes about one minute for the program to terminate. Note that the behaviour is different if asIterable() is used instead. In this case the program terminates immediately.

Context

I'm using Fedora Linux 41 and Java 23. I tested this with Mutiny 2.7.0 and 2.8.0.

[jponge]

This is because an executor is involved under the hood, and by default this is Executors.newCachedThreadPool() so the JVM will not terminate until all its threads expire.

You can tweak this by calling Infrastructure.setDefaultExecutor(...) and use another one.

Note that you don't have to do that if you are using Mutiny in Quarkus, as we already set an executor that's well integrated with the rest of the framework.

[lorenzpahl]

Thank you.