* frameworks: add ntex, salvo, carter, jooby, reitit (#1354) Also adds socketify, lithium and lwan disabled, each with the upstream defect that stops it recorded in its README. Every entry subscribes to the h1 profiles that are scored and nothing else: baseline, latency-1m, limited-conn, json, json-comp, json-tls, upload. That is the CATALOG's h1 family filtered on scored=True. It deliberately leaves out pipelined, which recently added entries do carry but which has been reference-only since #1058, and the static/database profiles for the same reason. Enabled, validate.sh 40 passed / 0 failed each: ntex Rust ntex::web on its tokio runtime salvo Rust Router tree, Compression hoop at level 1 carter C# Carter modules over ASP.NET Core and Kestrel jooby Java Jooby script API on Jetty reitit Clojure reitit-ring routing on the Jetty adapter Disabled, each blocked upstream rather than by the entry: socketify uWebSockets' parser rejects a request whose request line is split across TCP segments. Splitting at every byte offset, 4 through 35 fail -- the whole request line through its CRLF -- while every split in the headers or body succeeds. 30 passed / 10 failed, all fragmentation. lithium Its JSON serializer writes booleans as 1/0, and the json profile asserts the field is a boolean. Its decoder cannot read a JSON boolean at all, into a bool or an int, which is also why the dataset would not load. Enabling it needs an alternative JSON library and mode: tuned, or upstream fixes. lwan No chunked request bodies: neither "chunked" nor "Transfer-Encoding" appears in lwan-request.c, and a chunked POST answers 400. validate.sh sends chunked bodies in four places. Its POST cap also stays at the default despite max_post_data_size being set. json-tls is absent from its tests rather than failing, because lwan's TLS is kTLS with a 1.2 handshake and the profile requires 1.3. Three build traps worth carrying forward. plexus-compiler's in-process javac throws "Cannot load from object array because this.hashes is null" on JDK 25 at any maven-compiler-plugin version; fork=true takes another path. rust:1.94 is trixie and glibc 2.41, so pairing it with bookworm-slim as the runtime -- what the existing Rust entries do -- fails at startup on GLIBC_2.38 as soon as a binary references a post-2.36 symbol. lwan needs --whole-archive, since its module registry lives in linker sections whose boundary symbols only exist if something contributes to them. Jooby on Netty, its default server, never closes the socket on Connection: close -- it answers 200 with the right body and holds the connection, so all four fragmented GET shapes time out waiting for an EOF. Setting the header on the response did not change it. This entry uses jooby-jetty, which honours it. Claude-Session: https://claude.ai/code/session_016iyXstHcyyy1y47jAoBHid * socketify: attribute the fragmentation defect to socketify, not uWebSockets The PR body and README blamed uWebSockets' parser. That is wrong: the uWebSockets.js entries here pass the same byte-offset sweep cleanly -- hyper-express fails 0 of 71 splits -- so uWS handles a split request line. The defect is in socketify's bundled libsocketify, and it is not this entry's code either: a twelve-line socketify app whose only handler is `lambda res, req: res.end("55")` fails identically, at offsets 4-25 of its 24-byte request line. Also not fixable by upgrading. 0.0.31 is the newest release on PyPI and the actively maintained git HEAD ships a byte-identical libsocketify_linux_amd64.so (same md5), so it needs a rebuilt native library from upstream. Claude-Session: https://claude.ai/code/session_016iyXstHcyyy1y47jAoBHid * drop lwan: cannot serve json-tls Entries have to support every scored h1 profile. lwan's TLS is Linux kTLS with an mbedTLS 1.2 handshake behind the off-by-default ENABLE_TLS, and json-tls requires 1.3 -- validate.sh fails anything lower, so it was carrying 6 tests rather than 7. It also does not implement chunked request bodies at all: neither "chunked" nor "Transfer-Encoding" appears in lwan-request.c, and a chunked POST answers 400, which baseline and upload both send. Claude-Session: https://claude.ai/code/session_016iyXstHcyyy1y47jAoBHid * benchmark: all profiles for ntex salvo carter reitit Folds the results from the benchmark run into this branch so the entries and their numbers land together, rather than sitting in a second PR off main. axum.json is deliberately left at main's content. The run was on this branch, which was cut before #1361 merged, so regenerating from its stored rows would have reverted axum's baseline-4096 from 1,070,912 rps at 3745.7% CPU back to the pre-fix 755,895 at 3178.0%. jooby has no results: it never answered within the 30s readiness budget on the bench box and every profile was skipped. Claude-Session: https://claude.ai/code/session_016iyXstHcyyy1y47jAoBHid * jooby: size the Jetty thread pool, it never started on the bench box The entry came up on a 32-thread machine and died on the 64-core/128-thread runner, so every profile was skipped and it published no results: java.lang.IllegalStateException: Insufficient configured threads: required=290 < max=200 for QueuedThreadPool[worker] JettyServer.setOptions does setWorkerThreads(getWorkerThreads(THREADS)) against a hardcoded THREADS = 200, so leaving workerThreads unset does not fall back to Jooby's own WORKER_THREADS (cores * 8) -- it pins the pool at 200. Jetty sizes its selectors from ioThreads, which defaults to cores * 2, so the bench box asked for 256 selectors against that 200-thread pool and Server.doStart threw before anything listened. Below roughly 48 cores the budget stays under 200, which is why it passed validation locally. Now both are set: ioThreads = cores, workerThreads = max(512, cores * 8). Reproduced on a 32-thread box by forcing 256 selectors -- same exception, required=273 -- and confirmed the fix clears it under that same condition before re-validating: 40 passed, 0 failed. Claude-Session: https://claude.ai/code/session_016iyXstHcyyy1y47jAoBHid

Uh oh!

Frameworks to be added #1354

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions