> It was only slightly slower. (Netty vs virtual threads) that could easily just come down to implementation differences. I think this might be it. After my po

> It was only slightly slower. (Netty vs virtual threads) that could easily just come down to implementation differences. I think this might be it. After my post I thought about it and guessed that maybe the workload was potentially not an optimal netty workload, or there are aspects to the workloak that are not well suited for netty. I am unsure, however. > That said, it's definitely possible for the reactive libraries to simply use virtual threads whenever they do anything in parallel. That'd allow the model to avoid potential issues when calling into blocking code. Definitely would be a great enhancement for the elastic thread pool. > The benefit of virtual threads is making things even simpler so you don't need to understand those complicated constructs. You just spawn new threads whenever you need to run things in parallel. Once you get used to it, in my opinion, those constructs are simpler and easier to use than the standard multithreading options in java, specifically flux and timed operations. However, some items like request scope or session scope is a problem and harder (impossible?) to do right.