"A JVM threading model for the containerized times" by Luiz Hespanha and Flavio Brasil

[@mikeswierczek]

That's amazing. I'm especially impressed how Nauvoo throttles based on multiple metrics all together, not just CPU usage, or memory usage, or number of threads. One part I'd like to understand better is how systems reject work when they're overloaded. Does Nubank have everything going into the services using Nauvoo have some sort of automatic monitor-and-retry mechanism if a request fails, or do they have to engineer specific rejection handling based on the request type? Also, I love Clojure and the JVM but I wonder if the fact Nauvoo's metric collection and throttling logic is itself resource-intensive enough to mean that it might need to be written in C/C++/Rust/etc... and accessed through the JVM foreign function interface.

[@dmg46664]

Interesting

[@runderwo]

Don't recent JVMs solve this by allowing the number of GC threads to be limited by config flags (e.g. to the number of cores reserved to the pod)?

[@jayvkman]

Containers, processes, jvm as well as executors can be limited statically, but that may only work if you have a homogeneous workload, so this is an interesting way to monitor livelyness of the system and use that as hint to step on the gas/brakes and have more dynamic adaptive scaling.