Comments for https://horstmann.com/unblog/2022-04-15/index.html

Thanks for article.

Tomcat 10.1.0-M16 (beta) Released

The notable changes in this release are:

Refactor synchronization blocks locking on SocketWrapper to use ReentrantLock to support users wishing to experiment with project Loom.

Almost same code yours in SocketProcessorBase.java

Hi Horstmann,

I tested the virtual threads in my local machine comparing with "old" platform threads and the result surprised me that virtual threads are much worse (multiple times) than platform threads.
Below is my test function (the result is the same for both local or remote API). Could you give any advice as I'm quite confused now?

static void handleUrlVirtualThreads() {
    int nThreads = 10_000;
//    try (var executor = Executors.newFixedThreadPool(100)) {
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
      IntStream.range(0, nThreads).forEach(i -> executor.submit(() -> {
        try {
          var url = new URL("http://localhost:8090/hello"); //http://asia-southeast1.google.api.expert/ip
          try (var in = url.openStream()) {
            return new String(in.readAllBytes(), StandardCharsets.UTF_8);
          }
        } catch (IOException e) {
          throw new RuntimeException(e);
        }
      }));
    }
  }

I will download code.zip，just 404

Looks like this change is also included in Tomcat 9.1.74 now: "Refactor synchronization blocks locking on SocketWrapper to use ReentrantLock to support users wishing to experiment with project Loom."

Very useful article.. thanks so much.

As I mentioned in my other comment, I feel being non-blocking really shines when there are lots of long-waiting tasks mixed with lots of small tasks.
The blocking API / thread pools will wait for some of the long-waiting tasks to complete before taking up the small tasks. Whereas non-blocking will simply go through with the smaller tasks.
I believe that is the key benefit of Virtual threads.