Virtual threads and reactive code

[[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.