Virtual threads in action!

Helidon 4 became the world’s first web framework fully based on virtual threads - one of the major game changers in the industry! Virtual threads, which first appeared in Project Loom and then as a production feature in Java 21, dramatically improve resource usage in the JVM, allowing us to achieve performance comparable to reactive engines, but with a fully blocking paradigm. In this talk, I am going to tell you the story of Helidon WebServer - the problems and their solutions, the tasks it is designed to work on, and why it has changed the world of microservices frameworks.
Speaker: Dmitry Aleksandrov
Dmitry is a software developer at Oracle, a Java Champion, and an Oracle Groundbreaker. He’s currently working on Project Helidon. He has more than 19 years of experience, mainly in Java Enterprise in the banking and telecom industries, but he’s also interested in dynamic languages on the JVM and features like massive computations on GPUs. A true believer in open-source and community driven initiatives, he is a co-lead of the Bulgarian Java User Group and co-organizer of the jPrime conference.
Dmitry is a blogger and also a frequent speaker at local events as well as conferences like JavaOne/CodeOne, Devoxx, Voxxed, Joker, and JPoint.
#virtualthreads #loom #java #intellij #helidon #microservices
Join us:
Website: jb.gg/website
Blog: jb.gg/blog
Twitter: / intellijidea
Facebook: / intellijidea
Download IntelliJ IDEA: jb.gg/download-intellij-idea
Top 15 IntelliJ IDEA shortcuts: jb.gg/Top15IntelliJIDEAShortcuts

[@TheodoreRavindranath]

Great explanation. When all requests are fast - throughput is CPU bound. When some/all requests are slow, they change from being limited by thread-count to becoming CPU bound or bound by the next bottleneck. For example, even with virtual threads, if I am limited to 50 DB connections, then all DB-blocked virtual threads will be processed 50-at-a-time. However, even if 10,000 virtual threads are waiting for 50 DB connections, still small requests like container health checks will still go through with Virtual Threads. That last part is important! If you are resource-bound your tests may show no improvement with Virtual Threads! But, we may miss the fact that container health checks will still go through and container will not get killed/restarted when Virtual Threads are used. Also, in case of old thread pools, we would hit external APIs at a resonable rate. With Virtual threads, we may flood the external API and overwhelm them or get blocked. Need to take care of rate-limiting when moving to Virtual Thread.

[@JavaLovers]

Superb explanation..!!

[@Anbu_Sampath]

Nima (Helidon WebServer) need to be released as standalone artifact, so we can explore other frameworks on top it.

[@vladyslavnikolaienko4814]

You should reneme the video from Virtual Threads to Helidon in Action

[@Mpomp92]

My thoughts exactly. I expected to learn about implementing stuff WITH virtual threads and/or how they work in action. Not a showcase of Helidon...

[@IasonFilippou]

Do you guys think that with virtual threads we might be able to be done with the gore of callbacks, no matter how much we try to mask said gores with frameworks like promises? To be clear, I'm not looking for a debate on whether callbacks / promises are gory; I have respectfully reached an opinion *currently*, and it might change in the future. I'm simply wondering if you guys think that going back to blocking I/O will now be feasible with super-fast context switching offered by virtual threads.