What does "Needs a worker thread dispatch" mean on the endpoint REST score dashboard?

[kenyee]

I found this doc: https://quarkus.io/blog/resteasy-reactive-smart-dispatch/

but I don't understand why this resteasy reactive endpoint fails the execution check:

The endpoint should already be on a worker thread according to the link above.
T method(…​) | Worker thread

It does a Hibernate blocking call on it since I'm not using HIbernate reactive.
I also can't make this a suspend method for Kotlin coroutines because that's not compatible with non-reactive Hibernate and causes blocking since it runs on a Vertx I/O thread.

[kenyee]

figured out how to handle this for one API but the same technique doesn't work for another... I fixed one API by using a Uni that worke on a separate thread, but this doesn't work for this API

@Path("/upload/{project}")
    @POST
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces(MediaType.APPLICATION_JSON)
    fun uploadMetrics(
        @PathParam("project") project: String,
        @RestHeader(HEADER_APIKEY) apiKey: String,
        metrics: UploadMetricsData
    ): Uni<UploadResponse> {
        return Uni.createFrom().emitter<UploadResponse> { em ->
            .....some stuff that uploads data to a DB....
            em.complete(UploadResponse())
        }.runSubscriptionOn(executors.dbExecutor)
    }

Anyone know what would make this a "good" endpoint?
Can't find anything on stackoverflow for this warning msg....

[jdussouillez]

@kenyee I have a similar issue, did you find any solutions/workarounds ?

[kenyee]

Yes...I switched to using Uni on all endpoints.

…

On Tue, Oct 18, 2022, 4:57 AM Junior Dussouillez ***@***.***> wrote: @kenyee <https://github.com/kenyee> I have a similar issue, did you find any solutions/workarounds ? — Reply to this email directly, view it on GitHub <#23214 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEPHLSUQE6FXQ4WKQ2B4Z3WDZQ6VANCNFSM5M3GNNKQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mschorsch]

This ist not an issue. Dispatching on an worker thread means that you have a context switch, this can reduce your overall performance If and only If your are not doing any blocking operations. Blocking operations should run on a separate worker pool.

In your case you can probably annotate your method with @NonBlocking and remove Uni, but this depends on the kind of database operation your are doing (blocking or nonblocking)