(in case you're not in #announcements 🙂 )
Hi, I see many clojurians using HikariCP and with the advent of virtual threads. Are you using VT in production with HikariCP withou issues ? I'm asking because of https://github.com/brettwooldridge/HikariCP/issues/2151 . It seems this pull request with a long discussion about it https://github.com/brettwooldridge/HikariCP/pull/2055
Virtual threads are intended to be pretty much unlimited. Spawning thousands or even a million, and then having those start to pin on O/S threads, and you'll quickly run out of system resources...
I meant to ask, is the pinning the problem? Or in general, load-planning with freely-spawnable vthreads?
Pinning. If vthreads do not pin, they will be able to park and collaborate just fine into the millions.
Thanks for the insight! In your opinion is there anything a user of a library that uses synchronized blocks can do to circumvent this? Wrapping library calls in some way?
The recommendation from the Java folks is to switch from synchronized to reentrant locks. Which is what Clojure has done in 1.12 in the most critical pathways.
We are not using vthreads because we're on MySQL and that driver is very unfriendly to vthreads right now. I ran a test with Jetty 12 using vthreads and the JVM flag to identify pinning and it reported a huge amount of pinning even without much load. If you're using a JDBC driver that is more friendly to vthreads, you're still potentially going to overwhelm the connection pools and/or your database -- that's my reading of the discussion there (and it makes sense, based on my experience of tuning connection pools over the years).
Is pinning an issue? Isn't the worst case scenario "back to where we were with OS threads"?