Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird behaviour using Virtual Threads #2665

Closed
MYDIH opened this issue Oct 23, 2024 · 4 comments
Closed

Weird behaviour using Virtual Threads #2665

MYDIH opened this issue Oct 23, 2024 · 4 comments
Labels
Milestone

Comments

@MYDIH
Copy link

MYDIH commented Oct 23, 2024

Version

4.5.10

Context

Hi !

I have some intances in a production product where calling a specific endpoint will block a LivenessProbe enpoint and in the end kill my kubernetes pod. I just thought of the virtual threads implementation as an event loop spawning new virtual threads on each request (since it's cheap), now I'm not really sure anymore ...

Slightly off topic and potentially wrong

Some following issue though is that we can't use Future.await() in an executeBlocking handler ... Since the handler is run in a virtual thread, I would expect Future.await() to run properly, providing async/await like semantics. Drilling down a bit I saw that the context in the executeBlocking handler is not reported as an eventLoop context nor a blocking context (I think that isVertxThread is just false)

Reproducer

import static io.vertx.core.Future.await;

import io.vertx.core.AbstractVerticle;
import io.vertx.core.DeploymentOptions;
import io.vertx.core.ThreadingModel;
import io.vertx.core.Vertx;
import io.vertx.ext.web.Router;

public class TestVirtualThreads extends AbstractVerticle {
  @Override
  public void start() {
    try {
      Router router = Router.router(vertx);
      router
          .route("/health1")
          .handler(
              ctx -> {
                System.out.println("Health1: " + Thread.currentThread().getName());
                ctx.response().end();
              });
      router
          .route("/health2")
          .handler(
              ctx -> {
                System.out.println("Health2: " + Thread.currentThread().getName());
                await(
                    vertx.executeBlocking(
                        () -> {
                          System.out.println("Blocking: " + Thread.currentThread().getName());
                          Thread.sleep(10000);
                          return null;
                        }));
                ctx.response().end();
              });

      vertx.createHttpServer().requestHandler(router).listen(8080);
    } catch (Throwable e) {
      e.printStackTrace();
    }
  }

  public static void main(String[] args) throws InterruptedException {
    Vertx.vertx()
        .deployVerticle(
            new TestVirtualThreads(),
            new DeploymentOptions().setThreadingModel(ThreadingModel.VIRTUAL_THREAD));

    //noinspection InfiniteLoopStatement
    while (true) { // spurious wakeups
      synchronized (TestVirtualThreads.class) {
        TestVirtualThreads.class.wait();
      }
    }
  }
}

Steps to reproduce

  1. Hit the /health1 road and confirm it's responsive
  2. Hit the /health2 road and confirm it's blocking
  3. Hit the /health1 road while blocked on /health2 and see it's blocking too

Extra

Looks like disabling order in the executeBlocking call resolve this, but I don't understand why it impacts non-blocking calls though ...

Thanks for your time !

@MYDIH MYDIH added the bug label Oct 23, 2024
@vietj
Copy link
Contributor

vietj commented Oct 23, 2024

yes I see pretty much what the issue is and most likely we would need to use a different task queue for execute blocking

@vietj
Copy link
Contributor

vietj commented Oct 23, 2024

ordered false does not use this queue actually that is why it works correctly

@vietj
Copy link
Contributor

vietj commented Oct 23, 2024

this should fix the issue eclipse-vertx/vert.x#5365

@vietj
Copy link
Contributor

vietj commented Oct 23, 2024

@vietj vietj added this to the 4.5.11 milestone Oct 23, 2024
@vietj vietj closed this as completed Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants