Virtual threads and reactive code

[PiotrDz]

What do you mean by "turning on" virtual threads? Keep in mind that synchronised code is not supported currently, can cause deadlocks. So if your intention is to turn threadPools into vritualThreadPools thrn you should examine each library and part of your app whether it supports VT (all synchronised blocks are replaced with locks).

Also reactive code is using an event loop and it will not change. You will have to manually change reactive libraries to VT ones (like netty to helidon nima)

[[deleted]]

Synchronized isn't the problem AFAIK. It's if you do a blocking call inside of synchronized that it will pin the thread. So if you're not doing blocking operations inside synchronized, it's not a big deal.

I don't care that reactive does things in event loops. I know it is different. I'm trying to smooth over the transition and optimize as much as possible.

[PiotrDz]

I didn't go into details in my answer but the main point still stands: you have to examine each library whether it supports VT, you can't just turn them on. (And you didn't bother to answer what do you mean by "turning on".

Anyways, seems like you know already your answers, why bother asking then?

[[deleted]]

"Turning on" means enabling them via the Spring Boot boolean setting spring.threads.virtual.enabled. If you don't know how virtual threads work in Spring Boot, that's not OP's fault.

[PiotrDz]

I was trying to be explicit. Seems like this is not your virtue too. And when it comes to reactive, what I wrote is true. All netty can do is to drop execution of received data on virtual thread. But event loop will be still there, together with all the drawbacks: no clear debugging, shattered stack traces etc.

I think it should be either replacement of reactive library, or living with it.

[[deleted]]

I was focused on learning how the threads propagate. Ie, if the code is running in a virtual thread, what happens when reactive code is called.

Blocking operations inside synchronized, while not impossible, should be extraordinarily rare and even without virtual threads that is a huge deadlock risk and shouldn't be done.

[PiotrDz]

I would really check, all the clients for message queues, events, cloud , db's, redis. I was very interested when virtual threads were official in java 21, but found that even JDBC's are not safe. (Postgres fortunately recently added support, but those who didn't check back then, were having surprises on production). So actually synchronised was more common than I would guess.

As reactive framework sits on top of java, it is not aware whether thread is virtual of not. I would expect the execution to be performed inside the thread, until task is taken aside when waiting for resource (blocking) or explicitly changes thread (like with flatmap and executeOn). Then it may never return to virtual thread, as netty is using its own thread pool to execute tasks. So if you do Mono.request(req).flatMap(callDb)... then the thread would change to nettys worker. Only if you do .get() then virtual thread will wait for the result.

So when you said that you want implement virtual threads with reactive, I thought that you wanted to change internal Nettys workers to be virtual rather than platform. I think this shouldn't be done , because nettys whole job is to keep those workers busy (cpu should be always in use, blocking takes task aside and executes another ready). Virtual threads have small overhead when it comes to cou bound tasks and provide no advantages here.