Skip to content

Run Solid Queue inside Puma as threads - #35

Merged
6temes merged 1 commit into
mainfrom
solid-queue-async
Oct 6, 2026
Merged

6temes merged 1 commit into
mainfrom
solid-queue-async

Conversation

@6temes

@6temes 6temes commented Oct 5, 2026

Copy link
Copy Markdown
Owner

Solid Queue's Puma plugin forked a supervisor, dispatcher, scheduler and worker, and each fork is a full copy of the app (~200 MB) inside a 1 GB-class container. solid_queue_mode :async runs them as threads in Puma's own process instead. The database pool is now 100, since those threads share Puma's process and its pool.

Both lines sit inside if ENV['SOLID_QUEUE_IN_PUMA'], because solid_queue_mode only exists once the plugin has loaded; a bare call would crash Puma in development. Checked on the devbox with SOLID_QUEUE_IN_PUMA=1: solid_queue_processes lists the async supervisor, dispatcher and worker under Puma's own pid, and /up answers 200.

Same change in all four akamai apps (invoices, hydra, edu, deures). Merging deploys.

No UI change.

Each forked Solid Queue process (supervisor, dispatcher, scheduler,
worker) is a full copy of the app, about 200 MB each, inside a capped
container. In async mode they run as threads in Puma's own process, which
shares its database pool with Puma's threads, so the pool is 100.
@6temes
6temes marked this pull request as ready for review October 6, 2026 03:20
@6temes
6temes merged commit bd2a6a7 into main Oct 6, 2026
5 checks passed
@6temes
6temes deleted the solid-queue-async branch October 6, 2026 03:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant