RESTEasy Reactive Kotlin is using a Worker-Thread and not a Vert.x-Event-Thread

[mschorsch]

Describe the bug

Since Quarkus 2.0.0Alpha1 it is possible to implement suspend functions for REST endpoints. However, the executing thread is a worker thread (DefaultDispatcher-worker) and not, as expected, a Vert.x event thread (vert.x-eventloop-thread).

Expected behavior

The supend function is executed in a Vert.x event thread (vert.x-eventloop-thread).

Actual behavior

The supend function is executed in a worker thread (DefaultDispatcher-worker) from the GlobalDispatcher.

To Reproduce

@ApplicationScoped
@Path("/")
class TestResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    @Path("test")
    fun test(): String {
        return Thread.currentThread().name
    }

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    @Path("test2")
    suspend fun test2(): String {
        return Thread.currentThread().name
    }
}

Environment (please complete the following information):

Output of uname -a or ver

Microsoft Windows [Version 10.0.19041.928]

Output of java -version

openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode)

Quarkus version or git rev

2.0.0.Alpha1

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

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Java version: 11.0.10, vendor: AdoptOpenJDK
Default locale: de_DE, platform encoding: UTF-8
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Additional context

The problem is that GlobalScope is used without explicitly specifying a dispatcher. The default dispatcher, which works with its own worker pool, is then used by default (https://github.com/evanchooly/quarkus/blob/35c4fcab17f36606e2e4fbbdca6bac4f24aea45d/extensions/resteasy-reactive/quarkus-resteasy-reactive/runtime/src/main/kotlin/org/jboss/resteasy/reactive/server/runtime/kotlin/CoroutineInvocationHandler.kt#L16-L27).

Possible Solution (?): #10162 (comment)

[quarkus-bot]

/cc @FroMage, @evanchooly, @geoand, @stuartwdouglas

[pak3nuh]

Hi @evanchooly
I was actually trying to test this, because I also thought we needed to create an application's specific CoroutineScope and a Dispatcher that uses a vertex thread.
My issue is that the kotlin files aren't being picked up by the processor that generates the synthetic beans.
I'm sure I'm using a local build of quarkus with the latest artifacts.
Any pointers?

[cescoffier]

That is definitely a bug.

Not blocking the worker threads has almost no interest. What you don't want to block is the I/O thread. Co-routine should be dispatched on the Vert.x context handling the request.

[pak3nuh]

Hi all,

I've made some changes to capture the vertex context and run the coroutines on a vertex worker. It seems to run in the correct thread, but I'm very new to quarkus internals and I may missing something.
Also, I'd like your inputs because I believe we should expose the coroutine scope for user customization and I'm not sure how. Still learning how the extension mechanism works.

The changes are here, check it out https://github.com/pak3nuh/quarkus/tree/delegates-coroutine-to-vertex-worker

[FroMage]

Those changes look alright, but that module is currently being moved in #16838 so perhaps let's wait until that is merged before you open a PR here?

[pak3nuh]

Sure @FroMage, can you ping me when I have the green light?
In the meantime, I'll try to improve it and expose the configuration to the users.

[FroMage]

Sure, added a note there. Thanks.

[evanchooly]

@pak3nuh I just merged that other PR if you want to rebase.

[pak3nuh]

Hi all.
Just rebased onto the most recent main, but I'm trying to make the coroutine scope injectable instead of directly referenced.
If you need my changes ping me and I'll PR what I have now and improve it later.