Writing simpler reactive REST services with Quarkus Virtual Thread support

We need to include two Quarkus modules into the Maven dependencies. The first of them is Quarkus Resteasy Reactive which provides an implementation of JAX-RS specification and allows us to create reactive REST services. The quarkus-reactive-pg-client module provides an implementation of a reactive driver for the Postgres database. A similar API Thread.ofPlatform() exists for creating platform threads as well. Virtual threads do not support the stop(), suspend(), or resume() methods. These methods throw an UnsupportedOperationException when invoked on a virtual thread.

• When using Mutiny, alternative “xAndAwait” methods are provided to be used with virtual threads.
• Virtual threads, and their related APIs, are a preview feature.
• Today ExecutorServices are commonly used to limit the no. of platform threads that your app uses to execute async tasks.
• In the virtual threads nomenclature, this thread is called “carrier thread”.

The latest update to Java on Visual Studio Code improves the debugging experience thanks to support for the newly released Java 19. Keeping familiarity aside, why would one use Java/JVM instead of nodejs for the server of a web app? In Python you won’t get any concurrency by calling two async functions then awaiting each of them, but in Javascript you will.

Why Do We Need Virtual Threads?

So Spring is in pretty good shape already owing to its large community and extensive feedback from existing concurrent applications. ThrowIfFailed throws an exception that wraps one thrown by the child as a “caused by” and lists their stack traces. Java users have had this for many years, but threads were simply costly, so they were shared among tasks. The new thing structured concurrency brings — in addition to making some best practices easier to follow — is that the runtime now records parent-child relationships among threads .

The vast majority of blocking operations in the JDK will unmount the virtual thread, freeing its carrier and the underlying OS thread to take on new work. However, some blocking operations in the JDK do not unmount the virtual thread, and thus block both its carrier and the underlying OS thread. This is because of limitations either at the OS level (e.g., many filesystem operations) or at the JDK level (e.g., Object.wait()).

Vert.x virtual threads incubator

The risk is that a thread fails to reschedule/be preempted/end the loop in this timeslice but if the exact same interleaving happens to every other timeslice after, it shall never preempt. I preempt hot for and while loops by setting the looping variable to the limit from the kernel multiplexing thread. Having said all that, this sounds super cool and I think is 100% the way to go for Java. Would be interesting to revisit the implementation of something like Akka in light of this. There are people doing experiments with it where it shows some small performance gains even.

The task in this example is simple code — sleep for one second — and modern hardware can easily support 10,000 virtual threads running such code concurrently. Behind the scenes, the JDK runs the code on a small number of OS threads, perhaps as few as one. Server applications generally handle concurrent user requests that are independent of each other, so it makes sense for an application to handle a request by dedicating a thread to that request for its entire duration.

These changes do not impact code that extends these classes and assumes locking by the superclass, nor do they impact code that extends java.io.Reader or java.io.Writer and uses the lock object exposed by those APIs. All events, with the exception of those https://globalcloudteam.com/ posted during early VM startup or during heap iteration, can have event callbacks invoked in the context of a virtual thread. The GetAllThreads and GetAllStackTraces functions are now specified to return all platform threads rather than all threads.

Rate this Article

If it does cause trouble, let us know, because LTS really isn’t intended for actively maintained projects that want new features and isn’t the recommended path for them. Just note that the free upgrade services called LTS are not quite the same; they just include backports from mainline and don’t support the whole JDK. If an application benefitted from pooling jdbc connections with OS threads, I presume switching to virtual threads doesn’t impact that, and the application would continue to benefit by pooling jdbc connections. State of Loom , Ron Pressler, May 2020 – An older article written by the Loom project lead Ron Pressler. Adopting the use of virtual threads will therefore require using one or more of the above APIs.

Existing agents that enable the ThreadStart and ThreadEnd events may encounter performance issues since they lack the ability to limit these events to platform threads. The JDK’s virtual thread scheduler is a work-stealing ForkJoinPool that operates in FIFO mode. The parallelism of the scheduler is the number of platform threads available for the purpose of scheduling project loom java. By default it is equal to the number of available processors, but it can be tuned with the system property jdk.virtualThreadScheduler.parallelism. Note that this ForkJoinPool is distinct from the common pool which is used, for example, in the implementation of parallel streams, and which operates in LIFO mode.

I’m running the test four times using a different number of concurrent threads . Virtual threads help in achieving the same high scalability and throughput as the asynchronous APIs with the same hardware configuration, without adding the syntax complexity. The Thread API supports the creation of threads that do not support thread-local variables. ThreadLocal.set and Thread.setContextClassLoader throw an UnsupportedOperationException when invoked in the context of a thread that does not support thread locals.

It is a bit subjective, but regarding threading Java often chooses to expose the basic primitives as is, and let you build on top. Erlang is an opinionated specialization of concurrent programming en large, which may be a better for for certain problems, but not for others. I said in a sibling comment that scheduler activations may have been a flawed idea, but I don’t think the space of user-space scheduling APIs is fully explored. If io-uring is proof of anything, it’s that there’s still fundamental changes we can make in how we schedule work with the kernel. Project Loom experimentally proved that the benefit of virtual lies not in its fast context switches, but in the throughput afforded by having so many threads executed at once. The Go runtime has a work-stealing scheduler and does a lot of work to provide the same abstractions that pthreads have, but for goroutines.

Featured in Culture & Methods

Adding async/await would have required teaching all of them about this new construct, not to mention the need for duplicate APIs. I also feel like the reimplementation of all functions to support async is not a big deal because the actual pattern is generally very simple. You can start by awaiting every async function at the call site. Most OSes do offer a way to “pin” a thread to a processor (at varying levels of hint/requirement) but I’ve only seen them used when doing fairly extreme performance tuning. This extremely common misconception is not true of Linux or Windows. Both Windows and Linux have demand-paged thread stacks whose real size (“committed memory” in Windows) is minimal initially and grows when needed.

Perhaps that will change in future, but I do not anticipate it very soon. Under the hood, the vert.x Context class plays a critical part in maintaining the thread-safety guarantees of verticles. Most of the time, vert.x coders don’t need to make use of Context objects directly. If you want to know more about structured concurrency read this post.

This means developers must break their logic down into alternating IO and computational steps which are stitched together into a sequential workflow. / d
Littles Law doesnt care about what portion of the time is spent “doing work” vs “waiting”, or whether the unit of concurrency is a thread, a CPU, an ATM machine, or a human bank teller. It just states that to scale up the throughput, we either have to proportionally scale down the latency or scale up the number of requests we can handle concurrently.

1. Classic Threads or Platform Threads

Before we run load tests let’s add some test data to the Postgres database. We will use the Datafaker library for generating persons’ names. We will use the same reactive, non-blocking PgPool client as before. The following part of the code generates and inserts 1000 persons into the database on the Quarkus app startup. There are two specific scenarios in which a virtual thread can block the platform thread .

This allows virtual threads to park gracefully when methods are invoked reflectively. The java.io package provides APIs for streams of bytes and characters. The implementations of these APIs are heavily synchronized and require changes to avoid pinning when they are used in virtual threads.

Thread Pools are No Longer Needed

If something happens asynchronously it’s just IO and you can ignore that part. As far as you’re concerned it’s just one thread that you’re stepping over/into. Variable context, scope etc. are maintained the same and passed seamlessly.

Similar to traditional threads, a virtual thread is also an instance of java.lang.Thread that runs its code on an underlying OS thread, but it does not block the OS thread for the code’s entire lifetime. Keeping the OS threads free means that many virtual threads can run their Java code on the same OS thread, effectively sharing it. In async programming, the latency is removed but the number of platform threads are still limited due to hardware limitations, so we have a limit on scalability.

And the disadvantages of global shared memory, stop the world pauses etc. For sure it is a step in the right direction but it depends on where you stand wrt having shared mutable state in your programming model. It’s also not clear to me whether virtual threads can lock up carrier threads (e.g. due to an infinite loop) or are somehow preemptible (c.f. erlang reduction counts). Copying virtual stacks on a context switch sounds kind of expensive.

Virtual Threads: New Foundations for High-Scale Java Applications

Low-code and no-code tools can free up existing developers by reducing the time spent on integrating and administering DevOps toolsets. In this article, author discusses data pipeline and workflow scheduler Apache DolphinScheduler and how ML tasks are performed by Apache DolphinScheduler using Jupyter and MLflow components. We very much look forward to our collective experience and feedback from applications. Our focus currently is to make sure that you are enabled to begin experimenting on your own.