Hi Viraj! Is the course available for udemy business? I have a Udemy account from my company but I didn't find it

Hi Fabricio - Unfortunately no. If you send a message and request to Udemy, they might add it hopefully.

Hi Fabricio - Good News. Its now available as of yesterday ! Thanks !

@@viraj_shetty awesome!! I've just enrolled. Thank you so much 👏

Glad it was helpful!

Noted

Glad it was helpful!

I am glad you enjoyed it

My suggestion is to NOT rewrite your reactive application. But your next application should be evaluated to see if you can use Virtual threads. Currently Real time streaming data is the only thing which reactive programs can do better. If so, only that part should be made reactive. That's my thought ! Its an interesting video to make

I am glad you enjoyed the video

I am glad you liked it

Carrier thread is basically a Platform thread, so all objects are allocated in the heap. No change.

@@viraj_shetty I love your content! Thank you!

Glad you enjoyed it! 😊

Except for the streaming part of the reactive architecture, i think other parts are replaceable

Your instinct is correct. Java provides frameworks for writing Reactive applications. CompletableFuture (not Futures) and Spring WebFlux are two such mechanisms. But they don't mandate that the code is "Fully Reactive" because developers can always write blocking code and nothing can prevent that. Being fully reactive would require Developer due diligence as well. This video is more of a general discussion on reactive programming. I am creating a new video with code samples and I will publish that soon. Thanks for your comments !

Platform threads don't scale well. That's why we usually pool the Platform threads - say 200 max. That means if 5000 users are concurrently hitting your tomcat server - only 200 at time will be handled and that leads to severe performance problems (unless you add more tomcat instances). But the CPU is not maxed out at this point, so basically resources are not utilized properly. For the same requests, if you use Virtual Threads - there will be 5000 Virtual threads. Virtual threads are cheap, consumes memory in kbytes and under the hood they use Platform thread (Carrier) for CPU operations. But the important thing is that Virtual thread releases the carrier thread during IO operations like network io, file read/writing or locking. So, these 5000 Virtual threads will require only a few Platform threads (approx = num of cores). This improves the CPU throughput considerably. Virtual threads give us an illusion of more actual threads just like Virtual Memory gives us an illusion of more physical memory.

At the same time those 200 threads could fetch only, e.g., 200 db conections, but now they will exhaust the db connection pool

Glad you liked it !

Glad you enjoyed

Appreciate it very much

Check out the CompletableFuture tutorial. This talks about thread use. - 90 mins FREE Tutorial on Java Futures and Completable Futures kzfaq.info/get/bejne/htiYpNhzyta9ZJc.html

You are welcome !

Thanks! Glad you liked it

You are welcome !

Sure thing !

Glad you enjoyed

This discussion is for UI applications. Some use cases probably will continue using reactive style - like data pipelines . I agree there

Glad you enjoyed !

Java Virtual threads is an answer to Async-await except that it is just that it is automatic. Surely, it scales better than Platform threads. WebFlux does have the notion of streaming which will probably still be used.. But if you are using webflux primarily for scalability and optimal use of threads - then i would say Virtual threads would be a better fit.

That’s definitely an option.

Unfortunately it’s not always the choice of one developer.

Suspend functions and flow wrappers have the downside of function coloring.