New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Bundler::GemNotFound errors for nio4r gem #2427
Conversation
The `extra_runtime_dependencies` option allows one to activate gems in the puma master process after "pruning" the master process with `prune_bundler`. This is useful for activating gems that need to be loaded in the master process, such as `puma_worker_killer`. The integration test for `extra_runtime_dependencies` tested the `$LOAD_PATH` of the worker process instead. Since workers are forked from the master, it's normally fine to do this, but we might as well test the master process's `$LOAD_PATH` directly if we can.
LGTM. This code would normally not run on Windows (no fork, but maybe Windows 15?). There are a few places where |
Simple solution! |
We still need to defer loading of the Edit: actually, I'm not 100% sure on the Edit again: Opened #2436 to add an integration test to prevent regressions related to loading the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sss
Description
Fixes #2018
A fairly common and reasonable deployment strategy has been broken since the introduction of
nio4r
in puma 4.0. Imagine that a user is using puma in cluster mode. In order to deploy a new version of an application, a user's deployment tool does this:directory
in the config file)During the next deployment, workers will fail to start. They'll encounter the error
Could not find nio4r-2.5.1 in any of the sources (Bundler::GemNotFound)
. The root cause of the issue is described in rubygems/rubygems#4004. As of the time of writing, that issue is not yet addressed. This PR introduces a workaround into puma that essentially sidesteps the Bundler issue.The proposed change essentially just removes
nio4r
from being activated in the puma master process for cluster-mode puma as long as you're usingprune_bundler
(which is basically required anyway if you want phased restarts).nio4r
is used for doing async IO inPuma::Reactor
, and since in cluster-mode puma the master process doesn't actually run an instance ofPuma::Reactor
, we can defer loadingnio4r
until we're in the worker process.In addition to adding tests in puma itself for this change, I also verified that the repro in https://github.com/cjlarose/puma-phased-restart-could-not-find-gem-errors is fixed by the same change.
Your checklist for this pull request
[changelog skip]
or[ci skip]
to the pull request title.[ci skip]
to the title of the PR.#issue
" to the PR description or my commit messages.