diff --git a/README.md b/README.md index 96d33c6..ea75eba 100644 --- a/README.md +++ b/README.md @@ -84,7 +84,7 @@ service_past_wait: false # RACK_TIMEOUT_SERVICE_PAST_WAIT term_on_timeout: false # RACK_TIMEOUT_TERM_ON_TIMEOUT ``` -These settings can be overriden during middleware initialization or +These settings can be overridden during middleware initialization or environment variables `RACK_TIMEOUT_*` mentioned above. Middleware parameters take precedence: diff --git a/doc/settings.md b/doc/settings.md index 9a642c7..b0fadf6 100644 --- a/doc/settings.md +++ b/doc/settings.md @@ -58,7 +58,7 @@ If your application timeouts fire frequently then [they can cause your applicati - [Ruby Application Restart Behavior](https://devcenter.heroku.com/articles/what-happens-to-ruby-apps-when-they-are-restarted) - [License to SIGKILL](https://www.sitepoint.com/license-to-sigkill/) -**Puma SIGTERM behavior** When a Puma worker receives a `SIGTERM` it will begin to shut down, but not exit right away. It stops accepting new requests and waits for any existing requests to finish before fully shutting down. This means that only the request that experiences a timeout will be interupted, all other in-flight requests will be allowed to run until they return or also are timed out. +**Puma SIGTERM behavior** When a Puma worker receives a `SIGTERM` it will begin to shut down, but not exit right away. It stops accepting new requests and waits for any existing requests to finish before fully shutting down. This means that only the request that experiences a timeout will be interrupted, all other in-flight requests will be allowed to run until they return or also are timed out. After the worker process exists will Puma's parent process know to boot a replacement worker. While one process is restarting, another can still serve requests (if you have more than 1 worker process per server/dyno). Between when a process exits and when a new process boots, there will be a reduction in throughput. If all processes are restarting, then incoming requests will be blocked while new processes boot. diff --git a/lib/rack/timeout/core.rb b/lib/rack/timeout/core.rb index ae6247a..988131a 100644 --- a/lib/rack/timeout/core.rb +++ b/lib/rack/timeout/core.rb @@ -78,7 +78,7 @@ def initialize(app, service_timeout:nil, wait_timeout:nil, wait_overtime:nil, se raise(NotImplementedError, <<-MSG) The platform running your application does not support forking (i.e. Windows, JVM, etc). -To avoid this error, either specify RACK_TIMEOUT_TERM_ON_TIMEOUT=0 or +To avoid this error, either specify RACK_TIMEOUT_TERM_ON_TIMEOUT=0 or leave it as default (which will have the same result). MSG @@ -103,7 +103,7 @@ def call(env) seconds_waited = time_started_service - time_started_wait # how long it took between the web server first receiving the request and rack being able to handle it seconds_waited = 0 if seconds_waited < 0 # make up for potential time drift between the routing server and the application server final_wait_timeout = wait_timeout + effective_overtime # how long the request will be allowed to have waited - seconds_service_left = final_wait_timeout - seconds_waited # first calculation of service timeout (relevant if request doesn't get expired, may be overriden later) + seconds_service_left = final_wait_timeout - seconds_waited # first calculation of service timeout (relevant if request doesn't get expired, may be overridden later) info.wait = seconds_waited # updating the info properties; info.timeout will be the wait timeout at this point info.timeout = final_wait_timeout diff --git a/test/test_helper.rb b/test/test_helper.rb index 08c45c7..428e048 100644 --- a/test/test_helper.rb +++ b/test/test_helper.rb @@ -27,7 +27,7 @@ def app end end - # runs the test with the given environment, but doesnt restore the original + # runs the test with the given environment, but doesn't restore the original # environment afterwards. This should be sufficient for rack-timeout testing. def with_env(hash) hash.each_pair do |k, v|