Quartz thread discrepancy

[manofthepeace]

Describe the bug

After this PR #28348 . Scheduled method are not running on a quartz thread anymore. I do not understand the full intent, but from what I understands, scheduled methods should work on a vertx worker thread so it can be using a duplicated context.

This does work in JVM mode, but in native it runs on a executor thread (not sure about duplicated context here), which led a bit to this in our application; #32621, which we is why I could not reproduce locally in dev mode (jvm) as it runs on the vertx worker threads.

Expected behavior

In both jvm and native. if quarkus.quartz.run-blocking-scheduled-method-on-quartz-thread is true. Quarkus should use quartz threads. OK

In both jvm and native if the above property is unset or false, scheduled methods should run on a vertx worker thread. NOK

Actual behavior

When running in jvm mode:

2023-04-19 10:42:01,091 INFO  [org.acm.sch.Scheduler] (vert.x-worker-thread-0) Running scheduled task

When running in native mode:

2023-04-19 10:44:40,638 INFO  [org.acm.sch.Scheduler] (executor-thread-0) Running scheduled task

How to Reproduce?

Reproducer: https://github.com/manofthepeace/quarkus-thread-discrepancy

Steps to reproduce:
1- run the app in dev mode and look at the logs
2- compile native + run and observe the logs

Output of uname -a or ver

Darwin Kernel Version 21.6.0

Output of java -version

OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10

GraalVM version (if different from Java)

22.3.1

Quarkus version or git rev

2.16.6

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

Apache Maven 3.8.7

Additional information

No response

[quarkus-bot]

/cc @machi1990 (quartz), @mkouba (quartz)

[mkouba]

First of all, the different thread names don't mean that the job is not executed on a Vert.x worker thread. In Quarkus sometimes the Vert.x worker pool is backed by the default blocking thread pool (executor-thread-0) and sometimes it is not backed by this pool (vert.x-worker-thread-0). I know it's confusing but that's how it's implemented 🤷. For example, in the dev mode the default blocking thread pool is not used.

The correct way to detect a Vert.x worker thread is to use the io.vertx.core.Context.isOnWorkerThread() method; e.g. change the log line in your Scheduler class to something like log.info("Running scheduled task: " + io.vertx.core.Context.isOnWorkerThread()). You should see something like(executor-thread-0) Running scheduled task: true in both the JVM and native mode.

In any case, I did try to build and run your reproducer in native, JVM and dev mode and it behaves as expected and I did not observe the behavior described in #32621.

[manofthepeace]

Thank you for your reply. Is is really good to know about io.vertx.core.Context.isOnWorkerThread().

What really confuses me is that it makes it quite hard to properly "fine tune" thread pools in quarkus

as I am never exactly sure what will be taken in effect for those;

this quarkus.vertx.worker-pool-size vs quarkus.thread-pool.core-threads

this quarkus.vertx.keep-alive-time vs quarkus.thread-pool.keep-alive-time

For ManagedExecutor I seem to understand it is using quarkus.thread-pool, which is configurable at the injection point via @ManagedExecutorConfig. But the same is not possible for fireAsync or @Scheduled, which can together saturate the pool and render the ManagedExecutor somewhat "blocked"

unless again there's something I am not grasping.

[mkouba]

this quarkus.vertx.worker-pool-size vs quarkus.thread-pool.core-threads

CC @cescoffier

[cescoffier]

Hum, I'm not sure that quarkus.vertx.worker-pool-size is used in this case, but I need to check.

[mkouba]

The quarkus.vertx.worker-pool-size config property is deprecated since 3.4 (#35483). And in the prod mode the thread pool configured with quarkus.thread-pool.* config properties should be always used for blocking scheduled methods. In particular, the quarkus.thread-pool.max-threads config property should be used to specify the maximum number of threads (and the default value depends on the number of available processors).