BlockedThreadChecker does not check a parking event loop virtual thread about vert.x HOT 8 CLOSED

that is expected, the goal of the checker is to check threads which should not be blocked (like event-loop) or resources (worker threads) only.

from vert.x.

This is an event loop (I have a 2s timer example to show that the events are blocked), and should not be blocked for long. The special thing is that it's running on a virtual thread. It does provide some special powers like Future.await(), but should not affect its role as an event loop.

Virtual threads make blocking effective, and Future.await() makes events flow while parking. However, lots of other things are out of our control, e.g. maybe JDBC. I don't think block checker makes sense for Future.await(), since the events are flowing and vertx is happy, but for non-Future.await()ed parking/blocking, this could serve the same helpful insights as it does for non-virtual thread verticles.

from vert.x.

can you print the current thread to check it is an event-loop thread ?

from vert.x.

Both the verticle start code and the timer handler code run on vert.x-virtual-thread-x, not vert.x-eventloop-thread-x.
Example and output:

Code adjusted from previous post:

public final class NoBlockedWarningExample extends AbstractVerticle {
  @Override
  public void start() throws Exception {
    System.out.println(Instant.now() + " Starting on " + Thread.currentThread());
    vertx.setTimer(
        2000,
        event -> System.out.println(Instant.now() + " Timer handler on " + Thread.currentThread()));
    Thread.sleep(10000);
    System.out.println(Instant.now() + " Ending on " + Thread.currentThread());
  }

  public static void main(String[] args) throws ExecutionException, InterruptedException {
    final Vertx vertx = Vertx.vertx();
    vertx
        .deployVerticle(
            NoBlockedWarningExample.class,
            new DeploymentOptions().setThreadingModel(ThreadingModel.VIRTUAL_THREAD))
        .toCompletionStage()
        .toCompletableFuture()
        .get();
    vertx.close();
  }
}

Output:

2024-04-02T11:49:54.390115484Z Starting on VirtualThread[#23,vert.x-virtual-thread-0]/runnable@ForkJoinPool-1-worker-1
2024-04-02T11:50:04.412018302Z Ending on VirtualThread[#23,vert.x-virtual-thread-0]/runnable@ForkJoinPool-1-worker-1
2024-04-02T11:50:04.423519593Z Timer handler on VirtualThread[#23,vert.x-virtual-thread-0]/runnable@ForkJoinPool-1-worker-1

from vert.x.

unfortunately a vertx virtual thread is not an event loop thread

from vert.x.

I think I start to get what you mean. I take it this way: even though vertx.setTimer() is sending an event, but since it's not called on an event loop thread, it's not treated as an "event", but rather a task queued in the current thread.

Or, in another way, all 3 threading models are running an event loop / task queue, but just the EVENT_LOOP and WORKER threading models would get BlockedThreadChecker's attention.

from vert.x.

@azurvii yes because those are vertx managed resources, virtual threads are fully managed by the JVM (I wish we had more control on them)

from vert.x.

I'll be very careful where vertx.setTimer() and friends is called. Or just make everything fast enough.

I wish we had more control on them

My point was that Future.await() is already a very good control. My thinking was to reset the BlockedThreadChecker timer when starting await() and start a new timer when returning from await(). All other JVM managed thread parking activities are timed as if it's just running regular code. Since BlockedThreadChecker's concern should be how long the event loop / task queue is blocked, when it's not await() parking, it does not matter whether the thread is parked by JVM or actually executing code, they are "blocked" in BlockedThreadChecker's point of view. So we don't need "more control" to time them.

from vert.x.