puma 4.3.12 → 6.3.1

data/docs/stats.md

@@ -0,0 +1,142 @@
+## Accessing stats
+
+Stats can be accessed in two ways:
+
+### control server
+
+`$ pumactl stats` or `GET /stats`
+
+[Read more about `pumactl` and the control server in the README.](https://github.com/puma/puma#controlstatus-server).
+
+### Puma.stats
+
+`Puma.stats` produces a JSON string. `Puma.stats_hash` produces a ruby hash.
+
+#### in single mode
+
+Invoke `Puma.stats` anywhere in runtime, e.g. in a rails initializer:
+
+```ruby
+# config/initializers/puma_stats.rb
+
+Thread.new do
+  loop do
+    sleep 30
+    puts Puma.stats
+  end
+end
+```
+
+#### in cluster mode
+
+Invoke `Puma.stats` from the master process
+
+```ruby
+# config/puma.rb
+
+before_fork do
+  Thread.new do
+    loop do
+      puts Puma.stats
+      sleep 30
+    end
+  end
+end
+```
+
+
+## Explanation of stats
+
+`Puma.stats` returns different information and a different structure depending on if Puma is in single vs. cluster mode. There is one top-level attribute that is common to both modes:
+
+* started_at: when Puma was started
+
+### single mode and individual workers in cluster mode
+
+When Puma runs in single mode, these stats are available at the top level. When Puma runs in cluster mode, these stats are available within the `worker_status` array in a hash labeled `last_status`, in an array of hashes where one hash represents each worker.
+
+* backlog: requests that are waiting for an available thread to be available. if this is above 0, you need more capacity [always true?]
+* running: how many threads are running
+* pool_capacity: the number of requests that the server is capable of taking right now. For example, if the number is 5, then it means there are 5 threads sitting idle ready to take a request. If one request comes in, then the value would be 4 until it finishes processing. If the minimum threads allowed is zero, this number will still have a maximum value of the maximum threads allowed.
+* max_threads: the maximum number of threads Puma is configured to spool per worker
+* requests_count: the number of requests this worker has served since starting
+
+
+### cluster mode
+
+* phase: which phase of restart the process is in, during [phased restart](https://github.com/puma/puma/blob/master/docs/restart.md)
+* workers: ??
+* booted_workers: how many workers currently running?
+* old_workers: ??
+* worker_status: array of hashes of info for each worker (see below)
+
+### worker status
+
+* started_at: when the worker started
+* pid: the process id of the worker process
+* index: each worker gets a number. if Puma is configured to have 3 workers, then this will be 0, 1, or 2
+* booted: if it's done booting [?]
+* last_checkin: Last time the worker responded to the master process' heartbeat check.
+* last_status: a hash of info about the worker's state handling requests. See the explanation for this in "single mode and individual workers in cluster mode" section above.
+
+
+## Examples
+
+Here are two example stats hashes produced by `Puma.stats`:
+
+### single
+
+```json
+{
+  "started_at": "2021-01-14T07:12:35Z",
+  "backlog": 0,
+  "running": 5,
+  "pool_capacity": 5,
+  "max_threads": 5,
+  "requests_count": 3
+}
+```
+
+### cluster
+
+```json
+{
+  "started_at": "2021-01-14T07:09:17Z",
+  "workers": 2,
+  "phase": 0,
+  "booted_workers": 2,
+  "old_workers": 0,
+  "worker_status": [
+    {
+      "started_at": "2021-01-14T07:09:24Z",
+      "pid": 64136,
+      "index": 0,
+      "phase": 0,
+      "booted": true,
+      "last_checkin": "2021-01-14T07:11:09Z",
+      "last_status": {
+        "backlog": 0,
+        "running": 5,
+        "pool_capacity": 5,
+        "max_threads": 5,
+        "requests_count": 2
+      }
+    },
+    {
+      "started_at": "2021-01-14T07:09:24Z",
+      "pid": 64137,
+      "index": 1,
+      "phase": 0,
+      "booted": true,
+      "last_checkin": "2021-01-14T07:11:09Z",
+      "last_status": {
+        "backlog": 0,
+        "running": 5,
+        "pool_capacity": 5,
+        "max_threads": 5,
+        "requests_count": 1
+      }
+    }
+  ]
+}
+```

data/docs/systemd.md

@@ -1,21 +1,18 @@
 # systemd
 
-[systemd](https://www.freedesktop.org/wiki/Software/systemd/) is a
-commonly available init system (PID 1) on many Linux distributions. It
-offers process monitoring (including automatic restarts) and other
-useful features for running Puma in production.
+[systemd](https://www.freedesktop.org/wiki/Software/systemd/) is a commonly
+available init system (PID 1) on many Linux distributions. It offers process
+monitoring (including automatic restarts) and other useful features for running
+Puma in production.
 
 ## Service Configuration
 
-Below is a sample puma.service configuration file for systemd, which
-can be copied or symlinked to /etc/systemd/system/puma.service, or if
-desired, using an application or instance specific name.
+Below is a sample puma.service configuration file for systemd, which can be
+copied or symlinked to `/etc/systemd/system/puma.service`, or if desired, using
+an application or instance-specific name.
 
-Note that this uses the systemd preferred "simple" type where the
-start command remains running in the foreground (does not fork and
-exit). See also, the
-[Alternative Forking Configuration](#alternative-forking-configuration)
-below.
+Note that this uses the systemd preferred "simple" type where the start command
+remains running in the foreground (does not fork and exit).
 
 ~~~~ ini
 [Unit]
@@ -26,14 +23,20 @@ After=network.target
 # Requires=puma.socket
 
 [Service]
-# Foreground process (do not use --daemon in ExecStart or config.rb)
-Type=simple
+# Puma supports systemd's `Type=notify` and watchdog service
+# monitoring, as of Puma 5.1 or later.
+# On earlier versions of Puma or JRuby, change this to `Type=simple` and remove
+# the `WatchdogSec` line.
+Type=notify
+
+# If your Puma process locks up, systemd's watchdog will restart it within seconds.
+WatchdogSec=10
 
 # Preferably configure a non-privileged user
 # User=
 
-# The path to the your application code root directory.
-# Also replace the "<YOUR_APP_PATH>" place holders below with this path.
+# The path to your application code root directory.
+# Also replace the "<YOUR_APP_PATH>" placeholders below with this path.
 # Example /home/username/myapp
 WorkingDirectory=<YOUR_APP_PATH>
 
@@ -59,33 +62,31 @@ Restart=always
 WantedBy=multi-user.target
 ~~~~
 
-See [systemd.exec](https://www.freedesktop.org/software/systemd/man/systemd.exec.html)
+See
+[systemd.exec](https://www.freedesktop.org/software/systemd/man/systemd.exec.html)
 for additional details.
 
 ## Socket Activation
 
-systemd and puma also support socket activation, where systemd opens
-the listening socket(s) in advance and provides them to the puma
-master process on startup. Among other advantages, this keeps
-listening sockets open across puma restarts and achieves graceful
-restarts, including when upgraded puma, and is compatible with both
-clustered mode and application preload.
-
-**Note:** Any wrapper scripts which `exec`, or other indirections in
-`ExecStart`, may result in activated socket file descriptors being closed
-before they reach the puma master process. For example, if using `bundle exec`,
-pass the `--keep-file-descriptors` flag. `bundle exec` can be avoided by using a
-`puma` executable generated by `bundle binstubs puma`. This is tracked in
-[#1499].
-
-**Note:** Socket activation doesn't currently work on jruby. This is
-tracked in [#1367].
-
-To use socket activation, configure one or more `ListenStream` sockets
-in a companion `*.socket` unit file. Also uncomment the associated
-`Requires` directive for the socket unit in the service file (see
-above.) Here is a sample puma.socket, matching the ports used in the
-above puma.service:
+systemd and Puma also support socket activation, where systemd opens the
+listening socket(s) in advance and provides them to the Puma master process on
+startup. Among other advantages, this keeps listening sockets open across puma
+restarts and achieves graceful restarts, including when upgraded Puma, and is
+compatible with both clustered mode and application preload.
+
+**Note:** Any wrapper scripts which `exec`, or other indirections in `ExecStart`
+may result in activated socket file descriptors being closed before reaching the
+puma master process. For example, if using `bundle exec`, pass the
+`--keep-file-descriptors` flag. `bundle exec` can be avoided by using a `puma`
+executable generated by `bundle binstubs puma`. This is tracked in [#1499].
+
+**Note:** Socket activation doesn't currently work on JRuby. This is tracked in
+[#1367].
+
+Configure one or more `ListenStream` sockets in a companion `*.socket` unit file
+to use socket activation. Also, uncomment the associated `Requires` directive
+for the socket unit in the service file (see above.) Here is a sample
+puma.socket, matching the ports used in the above puma.service:
 
 ~~~~ ini
 [Unit]
@@ -108,26 +109,42 @@ Backlog=1024
 WantedBy=sockets.target
 ~~~~
 
-See [systemd.socket](https://www.freedesktop.org/software/systemd/man/systemd.socket.html)
+See
+[systemd.socket](https://www.freedesktop.org/software/systemd/man/systemd.socket.html)
 for additional configuration details.
 
-Note that the above configurations will work with Puma in either
-single process or cluster mode.
+Note that the above configurations will work with Puma in either single process
+or cluster mode.
 
 ### Sockets and symlinks
 
-When using releases folders, you should set the socket path using the
-shared folder path (ex. `/srv/projet/shared/tmp/puma.sock`), not the
-release folder path (`/srv/projet/releases/1234/tmp/puma.sock`).
+When using releases folders, you should set the socket path using the shared
+folder path (ex. `/srv/projet/shared/tmp/puma.sock`), not the release folder
+path (`/srv/projet/releases/1234/tmp/puma.sock`).
 
 Puma will detect the release path socket as different than the one provided by
-systemd and attempt to bind it again, resulting in the exception
- `There is already a server bound to:`.
+systemd and attempt to bind it again, resulting in the exception `There is
+already a server bound to:`.
+
+### Binding
+
+By default, you need to configure Puma to have binds matching with all
+ListenStream statements. Any mismatched systemd ListenStreams will be closed by
+Puma.
+
+To automatically bind to all activated sockets, the option
+`--bind-to-activated-sockets` can be used. This matches the config DSL
+`bind_to_activated_sockets` statement. This will cause Puma to create a bind
+automatically for any activated socket. When systemd socket activation is not
+enabled, this option does nothing.
+
+This also accepts an optional argument `only` (DSL: `'only'`) to discard any
+binds that's not socket activated.
 
 ## Usage
 
-Without socket activation, use `systemctl` as root (e.g. via `sudo`) as
-with other system services:
+Without socket activation, use `systemctl` as root (i.e., via `sudo`) as with
+other system services:
 
 ~~~~ sh
 # After installing or making changes to puma.service
@@ -136,35 +153,35 @@ systemctl daemon-reload
 # Enable so it starts on boot
 systemctl enable puma.service
 
-# Initial start up.
+# Initial startup.
 systemctl start puma.service
 
 # Check status
 systemctl status puma.service
 
-# A normal restart. Warning: listeners sockets will be closed
+# A normal restart. Warning: listener's sockets will be closed
 # while a new puma process initializes.
 systemctl restart puma.service
 ~~~~
 
-With socket activation, several but not all of these commands should
-be run for both socket and service:
+With socket activation, several but not all of these commands should be run for
+both socket and service:
 
 ~~~~ sh
 # After installing or making changes to either puma.socket or
 # puma.service.
 systemctl daemon-reload
 
-# Enable both socket and service so they start on boot.  Alternatively
-# you could leave puma.service disabled and systemd will start it on
-# first use (with startup lag on first request)
+# Enable both socket and service, so they start on boot.  Alternatively
+# you could leave puma.service disabled, and systemd will start it on
+# the first use (with startup lag on the first request)
 systemctl enable puma.socket puma.service
 
-# Initial start up. The Requires directive (see above) ensures the
+# Initial startup. The Requires directive (see above) ensures the
 # socket is started before the service.
 systemctl start puma.socket puma.service
 
-# Check status of both socket and service.
+# Check the status of both socket and service.
 systemctl status puma.socket puma.service
 
 # A "hot" restart, with systemd keeping puma.socket listening and
@@ -177,8 +194,8 @@ systemctl restart puma.service
 systemctl restart puma.socket puma.service
 ~~~~
 
-Here is sample output from `systemctl status` with both service and
-socket running:
+Here is sample output from `systemctl status` with both service and socket
+running:
 
 ~~~~
 ● puma.socket - Puma HTTP Server Accept Sockets
@@ -209,76 +226,14 @@ Apr 07 08:40:19 hx puma[28320]: * Activated ssl://0.0.0.0:9234?key=key.pem&cert=
 Apr 07 08:40:19 hx puma[28320]: Use Ctrl-C to stop
 ~~~~
 
-## Alternative Forking Configuration
-
-Other systems/tools might expect or need puma to be run as a
-"traditional" forking server, for example so that the `pumactl`
-command can be used directly and outside of systemd for
-stop/start/restart. This use case is incompatible with systemd socket
-activation, so it should not be configured. Below is an alternative
-puma.service config sample, using `Type=forking` and the `--daemon`
-flag in `ExecStart`. Here systemd is playing a role more equivalent to
-SysV init.d, where it is responsible for starting Puma on boot
-(multi-user.target) and stopping it on shutdown, but is not performing
-continuous restarts. Therefore running Puma in cluster mode, where the
-master can restart workers, is highly recommended. See the systemd
-[Restart] directive for details.
-
-~~~~ ini
-[Unit]
-Description=Puma HTTP Forking Server
-After=network.target
-
-[Service]
-# Background process configuration (use with --daemon in ExecStart)
-Type=forking
-
-# Preferably configure a non-privileged user
-# User=
-
-# The path to the puma application root
-# Also replace the "<WD>" place holders below with this path.
-WorkingDirectory=
-
-# The command to start Puma
-# (replace "<WD>" below)
-ExecStart=bundle exec puma -C <WD>/shared/puma.rb --daemon
-
-# The command to stop Puma
-# (replace "<WD>" below)
-ExecStop=bundle exec pumactl -S <WD>/shared/tmp/pids/puma.state stop
-
-# Path to PID file so that systemd knows which is the master process
-PIDFile=<WD>/shared/tmp/pids/puma.pid
-
-# Should systemd restart puma?
-# Use "no" (the default) to ensure no interference when using
-# stop/start/restart via `pumactl`.  The "on-failure" setting might
-# work better for this purpose, but you must test it.
-# Use "always" if only `systemctl` is used for start/stop/restart, and
-# reconsider if you actually need the forking config.
-Restart=no
-
-# `puma_ctl restart` wouldn't work without this. It's because `pumactl`
-# changes PID on restart and systemd stops the service afterwards
-# because of the PID change. This option prevents stopping after PID
-# change.
-RemainAfterExit=yes
-
-[Install]
-WantedBy=multi-user.target
-~~~~
-
 ### capistrano3-puma
 
-By default,
-[capistrano3-puma](https://github.com/seuros/capistrano-puma) uses
-`pumactl` for deployment restarts, outside of systemd.  To learn the
-exact commands that this tool would use for `ExecStart` and
-`ExecStop`, use the following `cap` commands in dry-run mode, and
-update from the above forking service configuration accordingly. Note
-also that the configured `User` should likely be the same as the
-capistrano3-puma `:puma_user` option.
+By default, [capistrano3-puma](https://github.com/seuros/capistrano-puma) uses
+`pumactl` for deployment restarts outside of systemd. To learn the exact
+commands that this tool would use for `ExecStart` and `ExecStop`, use the
+following `cap` commands in dry-run mode, and update from the above forking
+service configuration accordingly. Note also that the configured `User` should
+likely be the same as the capistrano3-puma `:puma_user` option.
 
 ~~~~ sh
 stage=production # or different stage, as needed
@@ -288,3 +243,4 @@ cap $stage puma:stop  --dry-run
 
 [Restart]: https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart=
 [#1367]: https://github.com/puma/puma/issues/1367
+[#1499]: https://github.com/puma/puma/issues/1499

data/docs/testing_benchmarks_local_files.md

@@ -0,0 +1,150 @@
+# Testing - benchmark/local files
+
+These files generate data that shows request-per-second (RPS), etc. Typically, files are in 
+pairs, a shell script and a Ruby script. The shell script starts the server, then runs the 
+Ruby file, which starts client request stream(s), then collects and logs metrics.
+
+## response_time_wrk.sh
+
+This uses [wrk] for generating data. One or more wrk runs are performed. Summarizes RPS and 
+wrk latency times. The default for the `-b` argument runs 28 different client request streams, 
+and takes a bit over 5 minutes.  See 'Request Stream Configuration' below for `-b` argument
+description.
+
+<details>
+  <summary>Summary output for<br/><code>benchmarks/local/response_time_wrk.sh -w2 -t5:5 -s tcp6</code>:</summary>
+
+```
+Type   req/sec    50%     75%     90%     99%    100%  Resp Size
+─────────────────────────────────────────────────────────────────    1kB
+array   13710    0.74    2.52    5.23    7.76   37.45      1024
+chunk   13502    0.76    2.55    5.28    7.84   11.23      1042
+string  13794    0.74    2.51    5.20    7.75   14.07      1024
+io       9615    1.16    3.45    7.13   10.57   15.75      1024
+─────────────────────────────────────────────────────────────────   10kB
+array   13458    0.76    2.57    5.31    7.93   13.94     10239
+chunk   13066    0.78    2.64    5.46    8.18   38.48     10320
+string  13500    0.76    2.55    5.29    7.88   11.42     10240
+io       9293    1.18    3.59    7.39   10.94   16.99     10240
+─────────────────────────────────────────────────────────────────  100kB
+array   11315    0.96    3.06    6.33    9.49   17.69    102424
+chunk    9916    1.10    3.48    7.20   10.73   15.14    103075
+string  10948    1.00    3.17    6.57    9.83   17.88    102378
+io       8901    1.21    3.72    7.48   11.27   59.98    102407
+─────────────────────────────────────────────────────────────────  256kB
+array    9217    1.15    3.82    7.88   11.74   17.12    262212
+chunk    7339    1.45    4.76    9.81   14.63   22.70    264007
+string   8574    1.19    3.81    7.73   11.21   15.80    262147
+io       8911    1.19    3.80    7.55   15.25   60.01    262183
+─────────────────────────────────────────────────────────────────  512kB
+array    6951    1.49    5.03   10.28   15.90   25.08    524378
+chunk    5234    2.03    6.56   13.57   20.46   32.15    527862
+string   6438    1.55    5.04   10.12   16.28   72.87    524275
+io       8533    1.15    4.62    8.79   48.15   70.51    524327
+───────────────────────────────────────────────────────────────── 1024kB
+array    4122    1.80   15.59   41.87   67.79  121.00   1048565
+chunk    3158    2.82   15.22   31.00   71.39   99.90   1055654
+string   4710    2.24    6.66   13.65   20.38   70.44   1048575
+io       8355    1.23    3.95    7.94   14.08   68.54   1048498
+───────────────────────────────────────────────────────────────── 2048kB
+array    2454    4.12   14.02   27.70   43.48   88.89   2097415
+chunk    1743    6.26   17.65   36.98   55.78   92.10   2111358
+string   2479    4.38   12.52   25.65   38.44   95.62   2097502
+io       8264    1.25    3.83    7.76   11.73   65.69   2097090
+
+Body    ────────── req/sec ──────────   ─────── req 50% times ───────
+ KB     array   chunk  string      io   array   chunk  string      io
+1       13710   13502   13794    9615   0.745   0.757   0.741   1.160
+10      13458   13066   13500    9293   0.760   0.784   0.759   1.180
+100     11315    9916   10948    8901   0.960   1.100   1.000   1.210
+256      9217    7339    8574    8911   1.150   1.450   1.190   1.190
+512      6951    5234    6438    8533   1.490   2.030   1.550   1.150
+1024     4122    3158    4710    8355   1.800   2.820   2.240   1.230
+2048     2454    1743    2479    8264   4.120   6.260   4.380   1.250
+─────────────────────────────────────────────────────────────────────
+wrk -t8 -c16 -d10s
+benchmarks/local/response_time_wrk.sh -w2 -t5:5 -s tcp6 -Y
+Server cluster mode -w2 -t5:5, bind: tcp6
+Puma repo branch 00-response-refactor
+ruby 3.2.0dev (2022-06-14T01:21:55Z master 048f14221c) +YJIT [x86_64-linux]
+
+[2136] - Gracefully shutting down workers...
+[2136] === puma shutdown: 2022-06-13 21:16:13 -0500 ===
+[2136] - Goodbye!
+
+ 5:15 Total Time
+```
+</details><br/>
+
+## bench_base.sh, bench_base.rb
+
+These two files setup parameters for the Puma server, which is normally started in a shell 
+script. It then starts a Ruby file (a subclass of BenchBase), passing arguments to it. The 
+Ruby file is normally used to generate a client request stream(s).
+
+### Puma Configuration
+
+The following arguments are used for the Puma server:
+
+* **`-C`** - configuration file
+* **`-d`** - app delay
+* **`-r`** - rackup file, often defaults to test/rackup/ci_select.ru
+* **`-s`** - bind socket type, default is tcp/tcp4, also tcp6, ssl/ssl4, ssl6, unix, or aunix
+  (unix & abstract unix are not available with wrk).
+* **`-t`** - threads, expressed as '5:5', same as Puma --thread
+* **`-w`** - workers, same as Puma --worker
+* **`-Y`** - enable Ruby YJIT
+
+### Request Stream Configuration
+
+The following arguments are used for request streams:
+
+* **`-b`** - response body configuration. Body type options are a array, c chunked, s string,
+  and i for File/IO. None or any combination can be specified, they should start the option.
+  Then, any combination of comma separated integers can be used for the response body size
+  in kB. The string 'ac50,100' would create four runs, 50kb array, 50kB chunked, 100kB array,
+  and 100kB chunked. See 'Testing - test/rackup/ci-*.ru files' for more info.
+* **`-c`** - connections per client request stream thread, defaults to 2 for wrk.
+* **`-D`** - duration of client request stream in seconds.
+* **`-T`** - number of threads in the client request stream. For wrk, this defaults to
+  80% of Puma workers * max_threads.
+
+### Notes - Configuration
+
+The above lists script arguments.
+
+`bench_base.sh` contains most server defaults. Many can be set via ENV variables.
+
+`bench_base.rb` contains the client request stream defaults. The default value for
+`-b` is `acsi1,10,100,256,512,1024,2048`, which is a 4 x 7 matrix, and hence, runs
+28 jobs. Also, the i body type (File/IO) generates files, they are placed in the
+`"#{Dir.tmpdir}/.puma_response_body_io"` directory, which is created.
+
+### Notes - wrk
+
+The shell scripts use `-T` for wrk's thread count, since `-t` is used for Puma
+server threads.  Regarding the `-c` argument, wrk has an interesting behavior.
+The total number of connections is set by `(connections/threads).to_i`. The scripts
+here use `-c` as connections per thread.  Hence, using `-T4 -c2` will yield a total
+of eight wrk connections, two per thread. The equivalent wrk arguments would be `-t4 -c8`.
+
+Puma can only process so many requests, and requests will queue in the backlog
+until Puma can respond to them. With wrk, if the number of total connections is
+too high, one will see the upper latency times increase, pushing into the lower
+latency times as the connections are increased. The default values for wrk's
+threads and connections were chosen to minimize requests' time in the backlog.
+
+An example with four wrk runs using `-b s10`.  Notice that `req/sec` varies by
+less than 1%, but the `75%` times increase by an order of magnitude:
+```
+req/sec    50%     75%     90%     99%    100%  Resp Size   wrk cmd line
+─────────────────────────────────────────────────────────────────────────────
+ 13597   0.755   2.550   5.260   7.800  13.310     12040    wrk -t8  -c16 -d10
+ 13549   0.793   4.430   8.140  11.220  16.600     12002    wrk -t10 -c20 -d10
+ 13570   1.040  25.790  40.010  49.070  58.300     11982    wrk -t8  -c64 -d10
+ 13684   1.050  25.820  40.080  49.160  66.190     12033    wrk -t16 -c64 -d10
+```
+Finally, wrk's output may cause rounding errors, so the response body size calculation is
+imprecise.
+
+[wrk]: <https://github.com/ioquatix/wrk>

data/docs/testing_test_rackup_ci_files.md

@@ -0,0 +1,36 @@
+# Testing - test/rackup/ci-*.ru files
+
+## Overview
+
+Puma should efficiently handle a variety of response bodies, varying both by size
+and by the type of object used for the body.
+
+Five rackup files are located in 'test/rackup' that can be used.  All have their
+request body size (in kB) set via `Body-Conf` header or with `ENV['CI_BODY_CONF']`.
+Additionally, the ci_select.ru file can have it's body type set via a starting
+character.
+
+* **ci_array.ru** - body is an `Array` of 1kB strings.  `Content-Length` is not set.
+* **ci_chunked.ru** - body is an `Enumerator` of 1kB strings.  `Content-Length` is not set.
+* **ci_io.ru** - body is a File/IO object.  `Content-Length` is set.
+* **ci_string.ru** - body is a single string.  `Content-Length` is set.
+* **ci_select.ru** - can be any of the above.
+
+All responses have 25 headers, total length approx 1kB.  ci_array.ru and ci_chunked.ru
+contain 1kB items.
+
+All can be delayed by a float value (seconds) specified by the `Dly` header
+
+Note that rhe `Body-Conf` header takes precedence, and `ENV['CI_BODY_CONF']` is
+only read on load.
+
+## ci_select.ru
+
+The ci_select.ru file allows a starting character to specify the body type in the
+`Body-Conf` header or with `ENV['CI_BODY_CONF']`.
+* **a** - array of strings
+* **c** - chunked (enum)
+* **s** - single string
+* **i** - File/IO
+
+A value of `a100` would return a body as an array of 100 1kB strings.

data/ext/puma_http11/PumaHttp11Service.java

@@ -1,18 +1,16 @@
 package puma;
 
 import java.io.IOException;
-        
+
 import org.jruby.Ruby;
 import org.jruby.runtime.load.BasicLibraryService;
 
 import org.jruby.puma.Http11;
-import org.jruby.puma.IOBuffer;
 import org.jruby.puma.MiniSSL;
 
-public class PumaHttp11Service implements BasicLibraryService { 
+public class PumaHttp11Service implements BasicLibraryService {
     public boolean basicLoad(final Ruby runtime) throws IOException {
         Http11.createHttp11(runtime);
-        IOBuffer.createIOBuffer(runtime);
         MiniSSL.createMiniSSL(runtime);
         return true;
     }

data/ext/puma_http11/ext_help.h

@@ -2,7 +2,7 @@
 #define ext_help_h
 
 #define RAISE_NOT_NULL(T) if(T == NULL) rb_raise(rb_eArgError, "%s", "NULL found for " # T " when shouldn't be.");
-#define DATA_GET(from,type,name) Data_Get_Struct(from,type,name); RAISE_NOT_NULL(name);
+#define DATA_GET(from,type,data_type,name) TypedData_Get_Struct(from,type,data_type,name); RAISE_NOT_NULL(name);
 #define REQUIRE_TYPE(V, T) if(TYPE(V) != T) rb_raise(rb_eTypeError, "%s", "Wrong argument type for " # V " required " # T);
 #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))