@Blocking does not work as expected with @PostConstruct

[jie-huang]

Describe the bug

When using @Blocking on @PostConstruct method, it is expected that should work.
But, it does not work when the class is used in a route of Uni<>.

@ApplicationScoped
public class BlockingInitResource {
  static class Data {
    public Data(String s) {
      this.s = s;
    }

    String s;
  }

  Uni<Data> initData() {
    return Uni.createFrom().item(new Data("hello"));
  }

  Data data = null;

  public Data getData() {
    return data;
  }

  @PostConstruct
  @Blocking
  public void init() {
    initData().onItem().transform(new Function<Data, Void>() {
      @Override
      public Void apply(Data d) {
        data = d;
        return null;
      }
    }).await().indefinitely();
  }
}

Expected behavior

Quarkus allow the blocking operation and can handle it smartly.

Actual behavior

Request failed: java.lang.IllegalStateException: The current thread cannot be blocked: vert.x-eventloop-thread-0

How to Reproduce?

https://github.com/jie-huang/quarkus-blocking

Run quarkus dev, then run curl http://localhost:8080/hello2

If you run curl http://localhost:8080/hello1 first, it works.
If you run curl http://localhost:8080/hello2 first, it fails.

Output of uname -a or ver

Darwin sd-lmc-1a8902 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:46:01 PST 2022; root:xnu-8020.240.18~2/RELEASE_ARM64_T8101 arm64

Output of java -version

openjdk 18 2022-03-22 OpenJDK Runtime Environment (build 18+36-2087) OpenJDK 64-Bit Server VM (build 18+36-2087, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.12.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 7.5

Additional information

No response

[geoand]

I would personally close this as won't fix as the @Blocking annotation is not a magic tool that can be used everywhere, but I'll let @cescoffier and @mkouba decide

[mkouba]

A @PostConstruct callback is always invoked on the thread where the bean instance is created (BlockingInitResource in this particular case is created on an event loop thread). And it may not return an asynchronous type, such as Uni. In fact, the CDI "bean construction API" is not asynchronous and so we may not easily integrate it with reactive libraries.

If you really need to do something similar you would need to @Inject Vertx and offload the logic manually via Vertx.executeBlocking(), but keep in mind that you might not block inside the callback anyway (no Uni.await().indefinitely() etc.). In other words, you'd need some kind of synchronization to ensure the data is initialized and ready for use.

[mkouba]

#27591 is related.