3 Commits

Include renames

Author	SHA1	Message	Date
clawbot	f743930f71	Default max_concurrent_processing to half the CPUs pixa sees (closes #242) ... The default max_concurrent_processing was one image per CPU pixa sees, so in a container with no CPU limit on a 48-CPU host pixa processed 48 images at once. It is now half the CPUs, rounded down and at least 1, defined once in internal/config; PIXA_MAX_CONCURRENT_PROCESSING stays the override, and a value that is not a whole number of at least 1 stops startup. "Running under upaas" gives the worst-case memory, 4.2 GiB per image (the largest peak measured over every source format and kind at 8192x8192) plus the upstream buffers, and the temporary file libvips keeps under /tmp. The two existing tests expect the new default, as the owner allowed. Model: opus-5-5	2026-10-15 23:07:22 +02:00
clawbot	00da62db2c	Exit with the shutdown's code and wait for image processing (closes #86) ... fx alone handles SIGINT and SIGTERM; the server's own handler, which only cancelled a context that fx's stop did not wait for, is gone. fx's Run exits with the shutdown's code: the one a shutdown request carries, 0 for a signal, 1 when the app fails to start or stop. A listen error asks fx to shut down with exit code 1. A Sentry DSN that cannot be used fails the server's start hook, so fx stops what had already started. The server's stop hook stops the HTTP server, then waits for the images still being processed, both within ShutdownTimeout; images still being processed after that are logged and fail the stop, so the exit code is 1. Model: opus-5-5	2026-10-04 04:59:30 +02:00
clawbot	baf457d21e	Bound concurrent image processing and upstream fetches (closes #64) ... Nothing bounded total in-flight work, so a burst of cache misses across hosts could exhaust memory. Two settings now do: max_concurrent_processing (default the CPUs Go uses) and upstream_connections (default 64, beside the per-host limit). A request that finds either full waits up to 10 seconds, then gets 503; a slot is released on every path. No request holds source bytes while it waits: a cached source is read only after the processing slot is taken, and a fetched one only while it holds its upstream connection. libvips runs one worker thread per image with its operation cache off. Both waits count toward downstream_timeout, as the README says. Model: opus-5-5	2026-09-29 10:32:16 +02:00