* Update extra_runtime_dependencies test to test master proccess's gems
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.
* Add test to refute that nio4r is loaded into puma master process
* Remove nio4r from puma master $LOAD_PATH
* Remove list of gems to activate from puma-wild
* Update History.md
Co-authored-by: Nate Berkopec <nate.berkopec@gmail.com>
* Actions non MRI - use JDK11 on macOS, add Big Sur
* Actions MRI - add macOS Big Sur Ruby 2.7
* test/helper.rb - run setup in same Timeout block as test
* TestIntegrationSingle#test_int_refuse - skip on JRuby
Seems to intermittently lockup CI
* TestLauncher#test_puma_stats - fix intermittent non-MRI failure II
* test_out_of_band_server.rb - JRuby - add small sleep after server.run
* test_persistent.rb - JRuby - add small sleep after server.run
* test_puma_server.rb - JRuby - add small sleep after server.run
* Revert api change from #2086 introduce Puma.stats_hash api
The change in #2086 is not backwards compatible with existing gems that parse the output of Puma.stats such as barnes.
Releasing a version of puma with this change would break anyone using the Barnes app and only in production. I'm proposing to keep the existing interface and instead add a new API. This buys us all the features of #2086 without causing any production facing downtime by customers due to API incompatibilities.
Unfortunately it requires that we serialize and the de-serialize the values. One prior benefit of returning json in a string was that it allowed an end user to de-serialize using a faster json algorithm such as `oj` via the "multi json" gem. But the performance penalty will be better than a stability break.
Before this commit, it was possible that the puma.state file would be world readable which may not be desirable in production environments. This introduces a new optional configuration option to set desired state file permissions.
* Add pumactl command to print thread backtraces
Completes 1 of 2 items from #1964
This commit adds an endpoint to the status app to print thread
backtraces, and control cli command to call that endpoint.
I tried this locally by starting a server with:
```sh
bundle exec bin/puma test/rackup/hello.ru \
--control-url="unix://test.sock" \
--control-token="token"
```
and then printing the backtraces with:
```sh
bundle exec bin/pumactl thread-backtraces \
--control-url="unix://test.sock" \
--control-token="token"
```
* Log threads as JSON in control app
With this commit the status app sends the thread backtraces as an array
of objects with `name` and `backtrace` keys, rather than as a string
matching the SIGINFO output.
While working on this I noticed that we logged the thread TID twice.
This commit simplifies that so we only log the thread TID once, with
both the label (I don't know when the label would get set) and name if
they are available.
* Allow extra runtime deps to be defined when using prune_bundler
* Check extra_runtime_dependencies is set before iterating over them
* Load additional paths for extra runtime dep gems
* Don't load extra dependencies, just add their paths to $LOAD_PATH
* Fix typos and extraneous checks and rescues
* Use Gem::Specification#full_require_paths when available
* Prevent use of prune_bundler and extra_runtime_dependencies with early versions of RubyGems
* Ensure LOAD_PATH is modified by extra_runtime_dependencies
* Refactor prune_bundler in launcher.rb and write some unit tests
