Add Virtual thread Netty NIO transport#6047
Add Virtual thread Netty NIO transport#6047franz1981 wants to merge 3 commits intoeclipse-vertx:masterfrom
Conversation
Run Netty NIO event loops as long-running virtual threads instead of platform threads. Uses ManualIoEventLoop from Netty 4.2 to manually drive IO polling and task execution from virtual threads, allowing the JVM's ForkJoinPool scheduler to multiplex event loops alongside other virtual threads. Adds VirtualThreadNioTransport (SPI), Transport.VIRTUAL_THREAD_NIO (public API), VertxTestBase support, and a VirtualThreadNio Maven profile to run the full test suite with this transport.
franz1981
force-pushed
the
virtual-thread-transport
branch
from
14babee to
9f7b8fb
Compare
| case "io_uring": | ||
| transport = Transport.IO_URING; | ||
| break; | ||
| case "virtual_thread_nio": |
There was a problem hiding this comment.
@vietj This could be implemented via the SPI in Quarkus straight on too TBH
@cescoffier I still see the value of having the lower level impls in Vertx if Vertx users can benefit of this
If not, I can send a PR to our Vertx 5 Quarkus branch or @jponge could port this too in the quarkus way.
|
The full benefits of this change would have been by allowing workers to be virtual threads. |
|
I think this rather should be an option of the NIO transport instead of being called a transport itself |
|
And do you want me to add a virtual thread worker too. to get the full benefits of this? |
|
worker are not related to transport, so that would be a different contribution |
|
@vietj 🙏 nice one, ok I will change the impl at this point and the CI seems happy (as it should be tbh) |
Move virtual thread event loop support from a standalone VirtualThreadNioTransport into a VertxOptions.virtualThreadEventLoops flag that enables ManualIoEventLoop-based VT event loops on the existing NIO transport. Native transports (epoll, kqueue, io_uring) are rejected when this option is set since JNI pins virtual threads.
Use Thread.Builder.OfVirtual.name(prefix, start) to create a named virtual thread factory directly, removing the hack that created throwaway platform threads just to steal their name.
|
PTAL @vietj Consider that NIO cannot be used before JDK 24 (included I think) and no other transport are possible w this |
| // Not cached for graalvm | ||
| private static ThreadFactory virtualThreadFactory(String prefix) { | ||
| try { | ||
| Class<?> builderClass = ClassLoader.getSystemClassLoader().loadClass("java.lang.Thread$Builder"); |
There was a problem hiding this comment.
in vertx 5.1 we will use multi release jar with Java 21, I think it should help.
|
I would like to understand how much this setting is important for end-user ? is that a user facing solution or just an advanced feature that is currently for evaluation purpose ? |
This is the "only" way to enable users (including Quarkus) to benefit of having a single thread pool (the ForkJoin one) to run Netty and blocking operations fully utilizing the machine capabilities. |
|
I'm only afraid that the feature is confusing for most users, so I would like to find a way to make it less obvious (e.g. internal kind of things) |
This is a good point, but the same would happen for transports: why a "normal" user should prefer NIO over "native EPOLL", both are epoll, at the end.. In this case, the sole reason why users would like to enable this is if they can use the "blocking" worker of Vertx to be powered by Loom as well, enabling both the internal core of Vertx and the "blocking" calls to actually runs on the same bunch of physical OS platform thread. |
|
I think the option is fine, I just want to find the proper naming for it to avoid create incorrect expectations from users and make it clear |
2 participants
Run Netty NIO event loops as long-running virtual threads instead of platform thread