Clojurians Log v2

Do you think it's ready for prime-time?

Well, I've had problems with vthreads several times so I'm still skeptical...

I'm in a wait-and-see pattern

Updating to the new alpha2 version on its own seems to work -- but has elevated CPU time but less TIMED_WAITING threads. Enabling the vthreads=target option caused heap to fill up and the server went into a 100% CPU GC tailspin. Still trying to track down exactly where things are breaking down.

Do you see a potential in being able to serve more users with less overhead (using vthreads)?

Since vthreads have less overhead, I would expect core.async-heavy code to potentially run faster -- since it's doing less work to context-switch. That said, I'd also expect it to use more heap (vthreads put their stack on the heap). With just the upgrade to core.async -- without explicitly turning on vthreads -- we do see better throughput, with more CPU usage, and fewer TIMED_WAITING as noted above.

I'm not sure yet, of where to use it (if at all). Wouldn't the webserver (e.g., jetty) have to know about this too?

When we first started trying vthreads, we saw all sorts of lock-ups and weird behavior -- I think that was back on JDK 19? On JDK 24, so far, they have been much more stable but we're only slowly rolling them out across our code.

Still not 100% of how it works on normal, end-to-end http request processing (not some abstract spin up 100000 threads to do some basic calculations)

Jetty can still use O/S threads and then your code can use vthreads.

Or you can switch Jetty to use vthreads if you want.

We're running with 25 at work

We can't use 25 until New Relic supports it (later this month).

How about when a request comes in, and jetty parks a thread, then your code uses vthreads, but then has to call to a db (or some external service, like, maybe S3 or Redis or summat)

I/O -- like DB access -- auto-parks vthreads and switches to another (depending on the JDBC driver).

interesting.

I'll watch this space with great interest