test-driven-learning VS avaje-jex

One approach I do not think many consider is starting with the Netty, which is used by many frameworks. We ended up using this for our current product, and while this gives the ultimate flexibility in handling requests it also heightens the bar somewhat for the ones employing its use, as it just gives you the nuts and bolts and it is up to you to make it play nice for your use-cases. I had to write quite a few learning tests to grok it.

I created https://github.com/avaje/avaje-jex ... with the hope of helping to move Javalin more in the Java direction but yeah, Javalin isn't going in that direction. So avaje-jex now will follow it's own path (as pretty much a web routing layer that abstracts over various http servers like jetty, grizzly etc with a java and loom focus).

Well, ultimately I instead ended up creating jex - https://github.com/avaje/avaje-jex

The Jetty ones use Jex and Loom based Jetty ThreadPool implementation ... and note that this isn't how the Jetty folks themselves have been playing around with Loom (see their loom branch). However, testing this just now against the latest 19 EA in what I think is the worst case scenario for Loom has: Loom at 80 rps and Traditional at 90 rps. Worse case scenario for loom meaning there is NO WAIT AT ALL in the response and that we do not exceed the Traditional Jetty thread pool size (testing at 100 concurrent clients which is less than default 200 max Jetty thread pool). As soon as we introduce IO wait + exceed the traditional thread pool size in terms of concurrent activity is when we see loom win out.