In the context of user-defined hooks (e.g. in `before_fork`), the previous naming had the unfortunate side-effect of causing `JSON` to resolve to `Puma::JSON` rather than, the likely more expected, `::JSON` module.
Closes#2639
* Add basic JSON serializer
For now, it only handles Arrays of Integers, but we'll extend it to
support all of the common types
* Serialize Strings
* Escape quotes in Strings
* Escape backslashes in Strings
* Serialize Hashes with String keys
* Extract method for serializing Strings
* Add test coverage for non-Hash non-Array JSON serialization
* Add test for unexpected key types
* Serialize Hashes with Symbol keys
* Raise on unexpected value types
* Serialize boolean values
* Serialize Floats
* Add module comment to Puma::JSON
* Update integration test to use fully-qualfied JSON module reference
* Remove json gem dependency from /stats status server response
Fixes a bug where requesting `/stats` from the status server would cause
subsequent phased restarts to fail when upgrading/downgrading the json
gem.
* Run gc_stats tests on JRuby
These were disabled at some point on JRuby, but they seem to run fine.
Importantly, this test ensures that a call to `/gc-stats` returns
well-formed JSON on JRuby, where the value of `GC.stat` contains nested
structures.
* Remove json gem dependency from /gc-stats status server response
Fixes a bug where requesting `/gc-stats` from the status server would cause
subsequent phased restarts to fail when upgrading/downgrading the json
gem.
* Remove json gem from /thread-backtraces status server response
Fixes a bug where requesting `/thread-backtraces` from the status server
would cause subsequent phased restarts to fail when
upgrading/downgrading the json gem.
* Remove json gem dependency from Puma.stats
Fixes a bug where accessing `Puma.stats` would cause subsequent phased
restarts to fail when upgrading/downgrading the json gem.
* Fix test name in json test
Co-authored-by: rmacklin <1863540+rmacklin@users.noreply.github.com>
* Add History entry
* Add test for exceptions on values of unexpected types
* Update test name for additional clarity
* Reorder cases to match order in ECMA-404
* Allow all serializable inputs in Puma::JSON::serialize
The pervious implementation was based on and older JSON standard which
defined JSON texts to be either objects or arrays. Modern JSON standands
allow all JSON values to be valid JSON texts.
* Update JSON tests to test value types directly
* Reorder tests to roughly match source order
* Add test for serializing integers as JSON
* Serialize nil as null
* Use block form of gsub instead of hash form
* Escape control characters as required by ECMA-404
* Collapse handling of Symbol and String into one case
* Extract constants used in string serialization
* Remove superflous else case
* Use stringio for incremental JSON construction
* Extract test helper for testing JSON serialization
* Assert that strings generated by Puma::JSON roundtrip when using ::JSON
* Use a recent version of the json gem in tests
`::JSON.parse` doesn't handle JSON texts other than objects and arrays
in old versions
* Handle default expected_roundtrip more explicitly for clarity
Co-authored-by: rmacklin <1863540+rmacklin@users.noreply.github.com>
* 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.
* Add frozen string literal everywhere it wasnt already
* Enforce stopgap for tests
* Small amount of integration test cleanup
* Parallelize and freeze Test_app_status
* Big cleanup for test_binder
* Whitespace fix
Right now to get stats for a puma process the only way is to go through the control server. The puma-stats-logger does this by reading in a state file then querying the control server manually.
7ad7798e9d/lib/puma_stats_logger/middleware.rb (L28)
Instead, I’m proposing adding a top level `Puma.stats` method that will allow anyone inside of the same process to get access to the stats.
This could be instrumented by a gem to theoretically export these stats to say a Heroku dashboard where we could list out backlog or thread count.
The format of stats is a hash, and will change depending on if the server is in “single” or “clustered” mode.
Clustered:
```
{ "workers": 2, "phase": 0, "booted_workers": 2, "old_workers": 0, "worker_status": [{ "pid": 19832, "index": 0, "phase": 0, "booted": true, "last_checkin": "2018-03-12T16:03:12Z", "last_status": { "backlog":0, "running":5 } },{ "pid": 19833, "index": 1, "phase": 0, "booted": true, "last_checkin": "2018-03-12T16:03:12Z", "last_status": { "backlog":0, "running":5 } }] }
```
Single:
```
{ "backlog": 0, "running": 2 }
```
Alternatively if we could somehow enable another process to get these stats from Puma via pumactl by default without requiring any additional in app config, that would also work.
This is a WIP. This was the minimum I could do to get all tests to pass without changing any tests. Eventually I think we want all high level process controls to come from launcher, I also think we want another separate object that gets passed to Runner/Single/Cluster that will maintain a relationship with the Launcher. We could use this as the object that also gets exposed to the app like the Embeddable class we talked about earlier.
Moving forwards i'm planning to port out the CLI tests to only test that they are parsing the correct config and launching servers. I'll port all low level unit tests over to the launcher. Making this change we could either keep all the public methods in CLI that delegate to `@launcher`, I'm guessing not many people are using the internals of CLI and we can take them out. It's your call though.
Wanted to kick this over the fence and see if you had any strong reactions or feelings about this approach.
