livery_req_sup (livery v0.2.0)

Per-request worker registry and concurrency cap.

Adapters call start_request/1 on every inbound request. The worker is spawned directly in the calling process (so spawning is not serialized through one process), then this gen_server is told to monitor it. Workers are temporary: a crashed request does not restart, the adapter sees the reset and serves the next stream.

In-flight requests are tracked in a lock-free counters array, not by enumerating processes: start_request/1 reads the count to enforce max_concurrent_requests (application environment, default

and answers {error, overload} past the cap, which the adapter turns into a 503. The count is incremented when a worker is admitted and decremented when this server sees the worker's DOWN, so a worker that is killed (which skips any in-process cleanup) is still accounted for. This bounds process and memory growth under a request flood. Operators should additionally bound the node with +P/+Q in vm.args (a library cannot impose those downstream); see config/vm.args.example.

The cap is a soft bound: the read-then-increment is not atomic, so a concurrent burst may admit a few past the cap, the same as the previous supervisor-count-based check.

Summary

Types

state()

Functions

handle_call(Request, From, State)

handle_cast/2

handle_info/2

in_flight()

Number of requests currently in flight (0 if the app is down).

init/1

start_link()

start_request(Args)

Spawn a new livery_req_proc worker, unless the in-flight count is at the max_concurrent_requests cap, in which case return {error, overload} so the adapter can shed load with a 503.