Description of problem: Puma, by default is a threaded web server, which means each http(s) request will be handled in a new thread. Since Rails' database connection pool reserves connections to threads, it's possible to exhaust the connection pool with enough web requests spinning up new puma threads. Thin, by contrast, still processes each request in a single thread by default. While this is usually slower, you don't have the issues of multiple threads in flight at the same time. We should make puma the default web server but have an easy option to switch to thin in case there are thread issues with puma. Version-Release number of selected component (if applicable): 5.6.0+
Upstream pull request: https://github.com/ManageIQ/manageiq/pull/10447
Upstream darga backport: https://github.com/ManageIQ/manageiq/pull/10713
From pull request: Purpose or Intent Puma handles each request in a new thread, leading to possible thread issues with the database connection pool, ActiveSupport::Dependencies interlock and our locks, or thread unsafe code in our application. Thin, while it may be run in threads via --threaded, does not use threads by default. See here This patch allows for thin 1.7.0+ and gives us an option to use either puma or thin. Note, earlier versions are not compatible with rack 2. We still default to puma. Steps for Testing/QA Note: Testers/users, the proctitle for UI/Webservice and web socket workers will look different in ps, top, etc. if you use thin instead of puma. Puma configures it's own proctitle and we configure the parts that we can. Thin does not, so it will look like all the other workers. For example: thin: 43177 ttys002 0:08.20 MIQ: MiqUiWorker id: 158, uri: http://0.0.0.0:3000 puma: 43871 ttys004 0:00.68 puma 3.3.0 (tcp://0.0.0.0:3000) [MIQ: Web Server Worker]
To change the web server, change puma to thin in the advanced configuration: :server: :rails_server: puma
*** Bug 1375328 has been marked as a duplicate of this bug. ***
Verified in 5.7.0.14