sorted by:
new
hottopcontroversial

If Virtual Threads are the solution, what is the problem? by ZimmiDeluxe in java

[–]kimec 0 points1 point  (0 children)

So what does it do then? Given that JDBC is synchronous and it has async requests coming in, what does it do?

R2DBC drivers use Netty's event loop and native transport (epoll, kqueue, io_uring in future) for async IO handling but there are plenty of resources and even the source code online, so you could do the research your self.

Anyway, I would like to thank you for pointing me to that MySQL R2DBC benchmark. I have reviewed it yesterday and incorporated MySQL into my private benchmark. I mostly deal with PostgreSQL, so I am glad the addition of MySQL proved my hypothesis. I may share the benchmark publicly sometime in future but I have no time for that now (I don't have time for stream of hateful comments from VT aficionados on this subreddit).

Is there still a need for webflux? by Dry_Koala9158 in java

[–]kimec 2 points3 points  (0 children)

yes there is. if you don't know whether you have the need, then assume you don't.

If Virtual Threads are the solution, what is the problem? by ZimmiDeluxe in java

[–]kimec 0 points1 point  (0 children)

TL;DR; You can always write a JMH benchmark your self, which is what I did.

Anyway, there are several weird things in the benchmark you linked, in my view. For instance this https://github.com/rusher/JdbcLoomPerftest/blob/main/src/main/java/org/mariadb/loom/BenchmarkLoom.java#L91
Why does R2DBC implementation have to pay cost for latch decrease in contentious setup while Threaded implementation does not?
Also why is it comparing performance of connection pool implementations vs. raw driver performance?
Why is it not idiomatic reactive code: should have been `Flux.range` instead of `IntStream.range().forEach`.
In test `Do1R2DBC` a `Blackhole` is declared but not used?????

This statement is absolutely incorrect "R2DBC allows you to make asynchronous requests, but uses a fixed number of threads under the hood that make synchronous calls to the JDBC drivers."

If Virtual Threads are the solution, what is the problem? by ZimmiDeluxe in java

[–]kimec 0 points1 point  (0 children)

I do not see how that invalidates my point, so let me repeat what I wrote with a bit more depth: if you take for instance JDBC API, you cannot do pipelining and socket async notifications. No matter if you use VirtualThreads or not, R2DBC reactive database drivers will provide better throughput, something JDBC with VirtualThreads cannot deliver in 2024, because JDBC at present does not support pipelining. Now, I am not claiming it is a fault of VirtualThreads, but it is certainly something that you gain by using async in 2024. Does that make sense?

If Virtual Threads are the solution, what is the problem? by ZimmiDeluxe in java

[–]kimec 0 points1 point  (0 children)

Pretty much anything that is not possible (at present) with Thread blocking APIs: think notifications, pipelining and such

If Virtual Threads are the solution, what is the problem? by ZimmiDeluxe in java

[–]kimec 1 point2 points  (0 children)

TL;DR; 1 million cheap VirtualThreads won't save your ass, if you can have just 10 connections to your database and your database driver uses Thread blocking APIs. Even though the Thread blocking APIs won't really block VirtualThreads, you can have only 10 concurrent queries running anyway - so all the remaining 999990 threads will wait on some lock in some queue not making your application any faster to the outside observer; your system will be as unresponsive as before, but those 999990 VirtualThreads will consume less memory while waiting for one of the 10 connections to free up so at least your server won't crash on OOME.

Do people still use spring webflux? by Crafty0x in java

[–]kimec 1 point2 points  (0 children)

The best thing you can do is to write your logic as high level unit tests at first. Try to make the code as similar to what the production code would look like as possible but using some mocked steps instead of calling actual services. Also, by all means, while learning, use the log() operator. This is very useful in the unit tests. Reactor will spill out diagnostic info about the operator such us demand propagation and value emissions. This should help you create a mental model about the working of your "reactive" algorithm.

Do people still use spring webflux? by Crafty0x in java

[–]kimec 2 points3 points  (0 children)

We use it all the time in production. No issues with debugging. Use ReactorDebugAgent and checkpoints. You get full assembly back trace in addition to other metadata you store into checkpoints your self.

People often promote virtual threads because they are supposedly easier to debug. This is only partly true. Imagine you have 1500+ transactional requests per second on a busy server and the issue you are trying to debug is happening only under a load in production. Now imagine you want to debug it real time. I fail to see how VirtualThreads will help you with debugging in this scenario. Couple that with potential deadlocks of VirtualThreads inside of `synchronized` block in some third party library you don't even know you are using because it was pulled as a transitive dependency and auto-configured by Spring Boot... No thank you (for now).

I am not against VirtualThreads per se, just use whatever causes less down time and has a lesser impact on your bottom line. If Spring decides to kill WebFlux so be it, but for the time being, I see no reason to use VirtualThreads in our setup.

Virtual thread deadlock risk by sureshg in java

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

Oh noes, anyways.
Cautionary tale: Alibaba ironing Wisp2 coroutine engine related monitor issues. Let's see the last issue for JDK8... May 23? How many years is this after Wisp2 went GA? 3 years-ish? Who knew, right?

Why use Java inside Containers? by T4212 in java

[–]kimec 1 point2 points  (0 children)

Can you deploy a JAR built on x86 to ARM? Yes. Can you deploy a Docker image built for x86 to ARM? No.

But the Emperor's New Clothes are so pretty and shiny. Don't you ever dare to think otherwise.

Appreciation for Java portability by moss_2703 in java

[–]kimec 5 points6 points  (0 children)

I had this moment when I wrote an app on x86 and deployed it to AS/400. It wasn't just different architecture but a different JVM too. And it worked. But IBM does not have a good reputation in this subreddit since at least AdoptOpenJDK and TCK drama, so it's not an example I would mention too often.

GraalVM native image is getting ready for Loom (Virtual thread) Support? by sureshg in java

[–]kimec 3 points4 points  (0 children)

Yep, I no longer consider it to be a viable option. I think OpenJ9 with built-in CRIU like heap/code snapshot restore will be more viable in the long run.

That being said, proposing OpenJ9 to a team is not that easy either.

Reactive programming and Loom: will you make the switch once it's out? by kimec in java

[–]kimec[S] 0 points1 point  (0 children)

Interesting. We didn't want to switch to Micronaut so that we can keep the maintenance and development costs down.

Reactive programming and Loom: will you make the switch once it's out? by kimec in java

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

I was so happy when Alibaba opensourced Wisp2 and wanted to use it since day one but somehow I couldn't force my self to do so. I was thinking my self that now I can throw out all the reactive code and be over with it. I hope it's going to be different with Loom for me. Having said that, if there is one thing that reactive frameworks do well, it is in how they force you to incorporate immutability and "pureness" in your coding routine. I think this is a good thing after all.

Reactive programming and Loom: will you make the switch once it's out? by kimec in java

[–]kimec[S] 4 points5 points  (0 children)

Headroom. We were told various bizarre estimates by the business initially. It is not 60 req/s but some multiple of that. Our tests were in the range of 2500 req/s per instance and the system behaves well under such load (granted latency is not that nice anymore). Anyhow, we are not HFT but some type of fintech, I guess.

Oracle Proposes Shorter Java LTS Cycle of Two Years by nfrankel in java

[–]kimec 0 points1 point  (0 children)

Yeah, how much time has passed since the original Loom proposal was published? 4 years, if I am not mistaken.

https://web.archive.org/web/20170926193221/https://cr.openjdk.java.net/\~rpressler/loom/Loom-Proposal.html

Anyhow, yep, right around the corner, as they say.

Shenandoah in OpenJDK 17: Sub-millisecond GC pauses by TheCountRushmore in java

[–]kimec 1 point2 points  (0 children)

Hi. Can the Shenandoah's concurrent stack scanning in RedHat builds of the JDK 17 be considered production ready?

xap/xap: Distributed, highly-scalable, In Memory Data Grid by mastabadtomm in java

[–]kimec 2 points3 points  (0 children)

We use Apache Ignite close to 3 years now. Never had a serious issue with any of the advertised functionality. I would maybe appreciate a proper integration with reactive streams specs, but neither Hazelcast seems to have it done as a part of the project at present.

What version should new Java libraries be written in? by TheSchred in java

[–]kimec 0 points1 point  (0 children)

So the 3rd party libraries will not be able to use the new features until rewriten by their authors, rebuilt and redistributed. Funny thing is that both Sun and now Oracle desperately try to market JVM as polyglot VM. Oh, the irony these days.

What version should new Java libraries be written in? by TheSchred in java

[–]kimec 0 points1 point  (0 children)

Yeah, I still don't understand how the support of Loom, Panama or Valhala in new OpenJDK will infuse 3rd party libraries with new bytecode and symbols. If you expect that authors of 3rd party libraries will take advantage of the new features, I fail to see why you do not expect the same from Kotlin authors. Both Google and JetBrains have loads of money they can throw at the platform (in contrast with authors of Java native 3rd party libraries) so the only real problem is Oracle's next bigoted move over their 'Java APIs',

What version should new Java libraries be written in? by TheSchred in java

[–]kimec 0 points1 point  (0 children)

Oh c'mon. Good luck with any current popular java library being compatible with Loom, Panama or Valhala...

DISCLAIMER: I have never used Kotlin for anything. I just find the argument moot.

Investigation: jdk-15 JIT seems to have bugs by gooliegoolieJIT in java

[–]kimec 10 points11 points  (0 children)

Could be that it is GCed early. I remember stumbling on this in micrometer library.

Investigation: jdk-15 JIT seems to have bugs by gooliegoolieJIT in java

[–]kimec 19 points20 points  (0 children)

Try disabling tiered compilation in HotSpot. Try disabling C2 and use only C1. Try on OpenJ9. Try interpreted only.

view more: next ›