Problem
The OpenAPI spec advertises 429 RateLimited (with Retry-After) on the validate endpoints and a maxRequestsPerMinute limit under GET /v2/metadata, but neither is enforced in the code. maxRequestsPerMinute is only echoed back in the metadata response, and validations run on Tomcat's full worker pool with no cap on how many run concurrently.
Validation is heap- and CPU-intensive, so an unbounded number of concurrent validations can oversubscribe CPU and push memory toward OOM (on container platforms the temp upload/output files also land on tmpfs, counting against the memory limit). For an unattended, single-warm-instance deployment we'd like the service to shed load gracefully rather than degrade or crash under a burst.
Proposal
A bounded-concurrency gate — e.g. a Semaphore sized by config (maxConcurrentValidations) — around the validation path that returns 429 + Retry-After when saturated, wired to the advertised maxRequestsPerMinute / surfaced in /v2/metadata.limits. This makes the documented 429 contract real and lets operators size an instance for a known concurrency ceiling.
Happy to contribute a PR. Context: surfaced while test-driving #1 for an unattended deployment that keeps one warm instance and absorbs occasional concurrent validations.
Problem
The OpenAPI spec advertises
429 RateLimited(withRetry-After) on the validate endpoints and amaxRequestsPerMinutelimit underGET /v2/metadata, but neither is enforced in the code.maxRequestsPerMinuteis only echoed back in the metadata response, and validations run on Tomcat's full worker pool with no cap on how many run concurrently.Validation is heap- and CPU-intensive, so an unbounded number of concurrent validations can oversubscribe CPU and push memory toward OOM (on container platforms the temp upload/output files also land on tmpfs, counting against the memory limit). For an unattended, single-warm-instance deployment we'd like the service to shed load gracefully rather than degrade or crash under a burst.
Proposal
A bounded-concurrency gate — e.g. a
Semaphoresized by config (maxConcurrentValidations) — around the validation path that returns429+Retry-Afterwhen saturated, wired to the advertisedmaxRequestsPerMinute/ surfaced in/v2/metadata.limits. This makes the documented429contract real and lets operators size an instance for a known concurrency ceiling.Happy to contribute a PR. Context: surfaced while test-driving #1 for an unattended deployment that keeps one warm instance and absorbs occasional concurrent validations.