I also wonder if the reactive libraries could be refactored to use the virtual threading model. It would help with a lot of the debugging issues. I would be sad to see those libraries go by the wayside as they do make a lot of complicated tasks simpler once you understand it.
The take away, IMO, is that without major architecture you can use blocking code and get near (and sometimes over) the same performance as you'd get with non-blocking code.
> I also wonder if the reactive libraries could be refactored to use the virtual threading model.
You could, but ultimately the question is "why?". One of the benefits of virtual threads is that the reactive model isn't as appealing.
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.
There might be a better avenue in the future if the JDK devs expose the underlying coroutine API (or parts of it) that powers virtual threads today.
> I would be sad to see those libraries go by the wayside as they do make a lot of complicated tasks simpler once you understand it.
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.
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.
One of the major changes to the JVM to make virtual threads work revolved around setting up the stack to be as light weight as possible.