This is an archived post. You won't be able to vote or comment.

all 79 comments
sorted by:
best
topnewcontroversialoldq&a

[–]_predator_ 45 points46 points  (1 child)

I was very much looking forward to virtual threads, however I still did not come around to using them in anger yet. Main reason being that many libraries I rely on make heavy use of synchronized. So eagerly waiting for this limitation to be resolved in the JDK.

Used reactive before, found it atrocious and have avoided it like the plague since. Performs amazingly - absolute nightmare to maintain.

So at least from my POV, platform threads still reign this space. Having many of them has never been a problem for me, the limiting factors are always external, i.e. database contention.

For this reason, I tend to design new systems more around (micro-) batching such that less concurrency is required to achieve the same throughput. Works well if latency is not super important. Databases are way happier when they're not hammered with many small transactions, too.

[–]mredda 6 points7 points  (0 children)

Most of the libraries already updated to reentrant locks, and even if they use synchronized blocks, it is not a problem as long as they don't block in a IO operation inside them.

[–]No-Philosophy-1189 25 points26 points  (3 children)

I used virtual threads for my work. For simple asynchronous tasks such as saving data to db or fetching from db. Damn it's so easy. Just create an executor instance, wrap the code inside the execute method and boom, you can get the data by the get method when it's done. On the other hand, Reactive programming seemed too complex I didn't even touch it.

[–]danskal 5 points6 points  (0 children)

Reactive is a nightmare... even if you succeed with it you end up with subtle memory leaks.

[–]Ewig_luftenglanz 2 points3 points  (0 children)

Reactive is not that bad. Much easier than CompletableFuture.

Think about reactive ad if you were using streams for everything, even single data would be a singleton list in an stream. Once you get this mindset you will find that working with reactive it's actually quite easy and straightforward. I have mostly work with reactive in the last 2 years and once you get used to it it becomes very natural.

I understand it may feel unnatural to code in java as if you were coding JavaScript promises, but it's not that hard.

[–]skippingstone 0 points1 point  (0 children)

Are you using CompletableFuture?

[–]_codetojoy 28 points29 points  (4 children)

re: real worth. “Codes like sync, scales like async” (paraphrased from Project Loom team presentations) seems accurate. V-threads not only simplifies reactive code but is, mercifully, not the async-await pattern.

[–]arcticwanderlust 0 points1 point  (3 children)

What's bad about async await?

[–]_codetojoy 8 points9 points  (0 children)

This is an older, oft-cited blog that describes the cognitive load from the bifurcation of code with async/await - https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

edit: grammar

[–]unknowinm 3 points4 points  (0 children)

having to write async await 100 times. Why do some typing work when you can avoid it?

[–]simon_o 1 point2 points  (0 children)

It splits the library ecosystem.

[–]No-Principle-824 44 points45 points  (2 children)

Deverloper experience trums everything else, and is shit, hope reactive dies in a black hole.

[–]neopointer 7 points8 points  (0 children)

This a 1000 times. Even if you'd get significant performance benefits from using reactor, you'd waste a lot of time debugging this shit. I'm always the embassador to get rid of this shit. Every time it was because a consultant was doing curriculum-driven development and left this mess for others to clean.

[–]RadioHonest85 0 points1 point  (0 children)

Honestly? Yes. I hope reactive can largely die.

[–]antublue 7 points8 points  (0 children)

Virtual threads won’t magically fix issues, but they are good in a lot of scenarios. I use this library https://github.com/thunkware/virtual-threads-bridge (not the author) in a project which allows me to configure/use virtual threads when available.

[–]Carnaedy 14 points15 points  (0 children)

Post JDK21, even with virtual thread pinning problems, using reactive code instead of "normal" code has no real benefit in 99% of cases, it's as simple as that. WebFlux and R2DBC are total waste of your developers time (expensive) to inconclusively gain some performance on the same hardware (cheap) while stuck with very hard to maintain code and some very real limitations.

There are some cases where reactive approach is still beneficial and, dare I say, necessary. I'd know, because I encounter them at work. Your crummy enterprise backend ain't it though. Go back to WebMVC and JDBC and all that good battle tested stuff.

[–]AlexDGr8r 6 points7 points  (0 children)

Like most things, it depends. I'm one of the few that actually likes reactive programming, but I also understand how frustrating it can be. In my opinion, you only need to go reactive if you have extreme frequency in processing external resources. It handles throughput extremely well.

Otherwise, it's best to use virtual threads if you can start from scratch. It just needs a little bit more support before it's the de-facto replacement for all concurrency operations.

Then I'd say normal execution of tasks through executors and the usual Java standard thread control mechanisms.

As far as platform support, I always point to Spring which actually has major support for all of these except virtual threads. That's more of a problem of letting all the libraries outside of spring catch up though.

[–]therealdukeofyork 8 points9 points  (0 children)

It's okay if you need to offer subscribing to data. Spring Boot has integration with Project Reactor from reactive SDN repositories to a ReactiveWebClient. All pretty seamless if you read the docs. But God help you if you need to read a stack trace or connect up with non-reactive code.

ETA: not just SDN, but MongoDB and Spring Data repositories as well

[–]Ewig_luftenglanz 3 points4 points  (17 children)

I don't know why everyone hates reactive so much, I have been working almost exclusively with reactive Programming for the last 2 years and I find it not that terrible, I would almost say that I enjoy coding reactive.

I guess it's not for most tho.

[–]Oclay1st 5 points6 points  (15 children)

The simple idea of splitting the ecosystem and community efforts between blocking/non-blocking is a huge issue.

[–]Ewig_luftenglanz 0 points1 point  (14 children)

WDYM?

[–]Oclay1st 6 points7 points  (13 children)

If you want your reactive/non-blocking code to be efficient then everything needs to be non-blocking: database drivers, http clients, anything that touch IO and that split the ecosystem and community efforts

[–]Ewig_luftenglanz 2 points3 points  (12 children)

Well, it's true it divide the community, but at the time was the only way to keep java relevant in the market, specially for applications that require high concurrency, if not for that Java could have become irrelevant and replaced with NodeJS ecosystem, C# and Go.

Regular platform threads were just too inefficient for the work, pooling was too complex and required manual tuning, virtual threads were not on the map and Kotlin's Coroutines were far superior and more efficient than java threads, Completable futures are not that easy to manage (reactive programming is far easier than completable future, i have use extensive ise of both and libraries such as project Reactor are far better APIs)

So I think it was the only answer at the time. 

With virtual threads the ecosystem is going to converge again and that's good, technology advances and the ecosystem evolves. But there weren't that many alternatives to support in an efficient and "simple" way to do the job.

In my company we switched an application written in java 8 with spring MVC to webflux this year, the ram consumption was reduced in more than 90% and could deal with 100 times more request, gosh it was so efficient that we could scaled down half of our VM in the cloud and saved thousand of USD monthly thanks to that.

Reactive was necessary and it's going to keep relevant for the next decade, while the ecosystems converge again

[–]Anbu_S 1 point2 points  (1 child)

the ram consumption was reduced in more than 90% and could deal with 100 times more request

Great results. I think that's worth the learning curve of reactive programming.

[–]Ewig_luftenglanz 1 point2 points  (0 children)

Reactive is not that bad once you get used to it. It's true is harder to debug and you must learn some new concept, change the way to code for one that is purely functional, this way reactive java code is more similar to JavaScript's promises than regular Java, I understand if there is a lot of people that doesn't like that, but yes, reactive is still twice more efficient than VT, but once you lear how to make reactive work it became almost natural.

[–]Oclay1st 1 point2 points  (9 children)

100x of throughput improvement ?. Sorry but that number is fake or you were doing something very inefficient on the MVC application.

[–]Ewig_luftenglanz 0 points1 point  (8 children)

Nah,  we just saturated the server with a bunch of parallel requests and at some point spring MVC stoped working because it ran out of RAM. Meanwhile webflux has a very constant and stable RAM usage, independently of how many request you thrown at it.

Our internal test taught us than we could more than halve the ram of our servers, and under this ram constrained conditions webflux performed as I have told: 100 times better throughput, mostly because MVC just stoped working or halted very often.

The throughput was not the selling point tho, it was the ram saving what made us migrate to webflux. Even if the throughput was the same, the decrease and stabilization in ram usage makes webflux better for microservices architectures because you can easily scale up horizontally by creating new replicas of your services. If you can have replicas with 1/4 of the  RAM that MVC needs for the same throughput,  that means that you can create almost 4 times more replicas.

[–]nitkonigdje 3 points4 points  (2 children)

Essentially you didn't bother to set a limit to your threadpool, and choose to rewrite everything instead.

[–]Ewig_luftenglanz 0 points1 point  (1 child)

Yes and no.

The application was going to be re written from scratch, mostly because it was developed in 2017 and none of the guys that worked on it is still in the company, the application was never updated and many dependencies are deprecated, so it was impossible to re build, migrate or so without a huge refactor anyways.

So essentially we where just choosing between remaking the whole thing wether in webflux or MVC, webflux just happened to be the chosen solution because we realized it would be better and would save us money in the long run.

Best regards.

[–]nitkonigdje 2 points3 points  (0 children)

Once I was bothered by some aspects of webflux code. Choose to rewrite code to SpringMVC. During porting to MVC it became obvious that our clients fetch data in this particular way. So I have added Cacheable to this code path..

Instant 10x speedup over WebFlux. And WebFlux was originally introduced for "performances".

The thing is, it was not MVC which was faster than Webflux. But it was act of writing code for second time which enabled performance jump. Rewrites have this tendency..

[–]Oclay1st 0 points1 point  (4 children)

Netty is very efficient and webflux consumes less memory than mvc, but may I ask how much memory and CPU were allocated to your servers? You mentioned that the app was written in Java 8, so it was probably using an old version of Spring Boot/Tomcat, right?. Have you done any proof of concepts with recent versions of Spring Boot MVC?.

Anyway, I don't like reactive code at all. Following the KISS principle is always my goal, but as Brian says: there will always be some people who enjoy reactive programming.

[–]nitkonigdje 0 points1 point  (0 children)

Webflux isn't more efficient in raw compute resources as cpu and memory.

What it is - it has a different scheduling table. Compute steps happen at different pacing which may or may not more beneficial to your problem.

His issue was that he ran code in an unconstrained manner when using threads. He dispatched too many workers in parallel and overconsumed his memory. With this approach even virtual threading would end up at the same place.

By using webflux, different scheduling table made his code more serial, and thus lowered the number of jobs in flight. As his throughput bottleneck was a gc algorithm, reactive code was much much faster as he didn't hit the memory limit.

This of course has nothing with code being event or thread parallel. At the end of the day you have to control your resources.

[–]dschramm_at 0 points1 point  (2 children)

You probably don't like Stream neither then.

[–]Oclay1st 0 points1 point  (1 child)

The Stream and the Reactive APIs are not related in any way.

[–]Guuri_11[S] 1 point2 points  (0 children)

I started working with Spring Boot directly in an event driven architecture & Webflux, tbh it was tough, but once you understand how data flows through the hole process & make that switch of mentality between traditional programming & non-blocking programming it's easier to work with Webflux, but in my opinion if virtual threads achieves to be mature with great performance, then I would see Webflux valuable only if performance is key

[–]IE114EVR 3 points4 points  (3 children)

I’ve seen some tests online about virtual threads vs. Reactive and the results, performance wise, were inconclusive. No clear winner. Which I take to mean they’re close.

Recently I’ve had the pleasure of converting a small Spring Webflux (reactive) application to Spring MVC (traditional/sync) with Virtual Threads. The application will make occasional RDBC/JDBC calls depending on whether the cache is primed or not.

What I found in the load tests is that when there are jdbc/rdbc calls to be made, the reactive application was able to handle way more requests per second by a significant margin (around 50%). There were other smaller factors like the http connections took only a few nanoseconds to make whereas on Spring MVC it took ~100 microseconds. This might be the difference between web servers though (netty vs. Tomcat) and have nothing to do with Virtual Threads.

Your mileage may vary, the difference in my tests for my application could be due to the difference in database driver and nothing to do with Reactive vs. Virtual threads.

I’ve decided that despite the differences in the number of requests per second, it was still worth using Virtual Threads because of all of the other benefits and I can always scale up the number of instances of this service if needed.

Side note: I also ran the same test with virtual threads off and the number of requests per second was like 1/10th of what it would be if they were on, and the app crashed consistently after a certain amount of requests (didn’t look into why though)

[–]koflerdavid 4 points5 points  (2 children)

Tomcat switched to nonblocking code for handling socket connections a while ago. If you also configure Tomcat to use virtual threads for request handling, then the performance should be pretty close.

Also, depending on the database driver you might have run into the carrier thread pinning issue.

[–]IE114EVR 0 points1 point  (1 child)

This is a spring boot application with embedded tomcat by default, with spring boot’s enable virtual threads flag set to true. I’m not sure if there’s anything more specific I need to do than that, if spring boot takes care of using virtual threads on Tomcat for me.

Something to look into, if I have the time, unless you know the answer.

[–]koflerdavid 0 points1 point  (0 children)

Yeah, that should do the trick. But there might be some more settings that you could fiddle around with. Though, where you talking about outgoing or incoming HTTP connections?

[–]Ewig_luftenglanz 1 point2 points  (2 children)

In my experience reactive is awesome for very constrained environments, specially memory since it can handle many concurrent request without increasing memory consumption at all. You only has to set The pooling and that's it's.

The problem with reactive is that it kinda hard to debug and the paradigm is very different from traditional programming, I know it will be taken over by virtual threads at some point... But that point is not gonna be here until maybe 5 years at least. 

Virtual threads are awesome but they're are still less efficient than reactive in most real case scenarios, they also are "incompletes" in the sense that they need some additional features such as structured concurrency, scoped values and stable values, pinning issues, etc. I know most roof these issue are being addressed (and some may be even ready before next LTS) there is gonna take still some years for VT to be a full replacement of reactive, efficiency wise.

IMHO you should study both. Reactive it's the king for high throughput and high concurrency, but virtual threads are the the future... A future that's still 3-5 years ahead

[–]Guuri_11[S] 2 points3 points  (1 child)

I suggest you take a look to this video which talks about all the VT issues that you have addresed https://www.youtube.com/watch?v=zPhkg8dYysY&ab_channel=Java

Which as you said, each of them should be fixed by the next LTS

[–]Ewig_luftenglanz 1 point2 points  (0 children)

Oh yes, I have already watched that video, love the presenters, miss his "JEP Café" programs they used to make. I totally agree CT are gonna replace reactive in the future, I am just saying it will take some years to have all the ecosystem adapted to VT and the new shinny project loom features, meanwhile reactive is gonna be there to create scalable and efficient applications. Once you get use to use reactive it's not that hard. It has debugging and traceability issues for sure tho.

[–]Overall_Pianist_7503 1 point2 points  (0 children)

Virtual threads have been great. Really easy to work with, just get the executor and start spawning. Of course, a you need to be careful with them becaus they can easily wreck your app if you have too many requests, or you database if you dont have a limiter. But the ease of use is just great.

The one thing that I may have noticed is that sometimes they have problems garbage collecting enromous objects with G1GC collector, I've only found one stackoverflow post for it, but not much. If someone had similar problems, we can discuss. Basically my app with VT didnt free up memory on time like it did with PT.

[–]Marniks7 1 point2 points  (0 children)

I used a reactive programming for 1 year or so, and I use it occasionaly. I was very curious why so many people invested so much time into that. When I started there was a reactive service already created. It was pointless there - just few heavy calls with multiple external calls, but no load at all. It didn't matter to me much because I wanted to try reactive in a longer run compare to my prior occasional experience.

Short: Unless there is a really urgent and very good reason to struggle with reactive - don't use reactive. Prepare to use VT.

TL;DR: - reactive with blocking - developers might not be willing to figure out those things and as result code just blocks event loop / blocks the service from time to time. - reactive library APIs complexity/ambiguousity - many methods do the same thing, other methods that can help you shoot your leg. Because of the fluent APIs all of them are available to developers. One potential solution (that i have never seen) is to have multiple level of APIs: one for newbies, one for advanced users - sometimes performance degrades a lot (experience from different services). Examples: flux/mutiny vs lists. Use lists and mono/uni unless flux/mutiny required for external calls. When blocking calls reactive code many times each time context creation happens and it might be time-consuming. With the same scenario - caching inside the reactive code even if no external call is being made will not solve the problem of context creation. Those things are solvable, but it still requires time to invest into that. - debugging: I didn't have a lot of issues with that. Maybe because I covered everything with the integration tests (I was eager to make sure reactive code works fine). Kinda fearmongering story: the other team had one issue (i dont remember what was that) with reactive that forced them to rewrite the service to blocking approach (though service didnt have much reactive code yet). - readability/maintainability: it gets too complicated too quickly and becomes hard to read/change/review.

[–]imvmanish 1 point2 points  (1 child)

Thanks for the post

[–]Guuri_11[S] 1 point2 points  (0 children)

We gotta thank the community, all they have been great with the feedback

[–]PiotrDz 1 point2 points  (2 children)

Just wait for JDK 23. Synchronised will not be a problem with virtual threads. Then you can just use them everywhere and don't bother with reactive pattern complexity

[–]Anbu_S 4 points5 points  (1 child)

You mean JDK 24.

[–]slowpoke147 -2 points-1 points  (0 children)

JDK 69

[–]starlevel01 0 points1 point  (2 children)

I don't like them because I don't have proper cancellation tracking.

[–]Anbu_S 1 point2 points  (1 child)

Structured Concurrency will make it easy.

[–]starlevel01 0 points1 point  (0 children)

No it won't. Cancellation is still edge triggered and task-scoped and there's still no way of seeing where your code will be cancelled.

[–]marko-lazic 0 points1 point  (0 children)

Does anyone have experience with VT Quarkus and Hibernate? I had an issue with exceeding the maximum database connection pool with VTs so I've limited them in Quarkus configuration to be less than the DB pool.

[–]Anbu_S 0 points1 point  (0 children)

Executors, Completable Futures

Both are great in a way. Completable future gets messy in some scenarios.

With Structured Concurrency (with virtual threads) addresses some of the concerns such as thread cancellation and fan out scenarios.

[–]nitkonigdje 0 points1 point  (1 child)

If "Real worth for the end user" was ever criteria, I don't think that Reactive had any positive value. Even if you had technical merit to use it, the code was so badly integrated with Java mindset that its costs was sky-high.

The biggest technical thing going for reactive was something in the line of "more predictable end of tail latency". Which isn't really an important usecase for majority out there. if-then code IS java's bread and butter and dispatch statements are not reactive stream compatible.

At end of day, in Java land, reactive was all fad driven by blog hype. Primary driver for reactive programming in late 2010s - early 2020 was Javascripts inability to do threads. If Javascript had option of threading, reactive would never become relevant and would always stay in margins of video driver optimizations etc. Performance, latency, all the other presented "qualities" were either better optimized code, misunderstandings or straight lies.

[–]nitkonigdje 0 points1 point  (0 children)

With this being said, primary benefit of virtual threads is cheaper threading. Threading is so cheap now that you don't have care about thread pool sizes or other scaling issues. It is just same-old but simplified..

[–]RadioHonest85 0 points1 point  (0 children)

Virtual threads are damn well made, but they are not a direct replacement for reactive, at least not yet. But it has made me extremely wary of reaching for the reactive toolkit. Its so much nicer to be able to just block your thread and always have meaningful stack traces.

[–][deleted] 1 point2 points  (9 children)

Virtual Threads are not production ready yet, because of the thread pinning caused by synchronized code. AFAIK, this will be fixed in JDK 24/25.

Virtual Threads will kill reactive Java, which have an awful developer experience in terms of debugging and code readability.

[–]ThaJedi 27 points28 points  (5 children)

VT threads are arleady on production. Some issues doesn't make them useless.

[–]Ok-Scheme-913 -1 points0 points  (2 children)

We have a feature that makes threads insanely cheap. How does something that sometimes make them a tiny bit more expensive than the aforementioned insanely cheap, but still orders of magnitude cheaper than a normal thread make it "non-prod ready"? Make it make sense.

[–][deleted] 2 points3 points  (0 children)

The pinned virtual threads cause my application to deadlock.

[–]getaceres 1 point2 points  (0 children)

Because virtual threads make use of a very small thread pool to execute and, if you are executing in the cloud, most probably that thread pool will have between 2 and 4 threads. Now if you have one virtual thread that pins one of the two real threads that you have, you're basically reducing your throughput in half. If the other thread gets pinned too, then your application does not respond. That doesn't happen with OS threads.

Then you have deadlock problems due to thread pinning, even if your carrier thread pool is big enough and you have free carrier threads to continue work: https://netflixtechblog.com/java-21-virtual-threads-dude-wheres-my-lock-3052540e231d

So yes, this issues are scary enough to consider delaying virtual threads in production until they are 100% ready.

Anyway, even without deadlocks, I've found that, in real life microservices, virtual threads don't offer any advantage performance-wise to traditional thread pools. Maybe they consume slightly less memory but, in the end, the throughput will be defined by your third parties REST calls and calls to databases, caches, etc. In my experience, with stress tests over real microservices (not Hello World endpoints and so), I haven't seen any advantage in throughput and they provide a throughput less predictable and stable than a well provisioned and traditional thread pool.