Redirecting to http://rainbows.bogomips.org/Rainbows/ThreadTimeout.html ...
Soft timeout middleware for thread-based concurrency models in Rainbows! This timeout only includes application dispatch, and will not take into account the (rare) response bodies that are dynamically generated while they are being written out to the client.
In your rackup config file (config.ru), the following line will cause execution to timeout in 1.5 seconds.
use Rainbows::ThreadTimeout, :timeout => 1.5 run MyApplication.new
You may also specify a threshold, so the timeout does not take effect until there are enough active clients. It does not make sense to set a :threshold higher or equal to the worker_connections Rainbows! configuration parameter. You may specify a negative threshold to be an absolute value relative to the worker_connections parameter, thus if you specify a threshold of -1, and have 100 worker_connections, ThreadTimeout will only activate when there are 99 active requests.
use Rainbows::ThreadTimeout, :timeout => 1.5, :threshold => -1 run MyApplication.new
This middleware only affects elements below it in the stack, so it can be configured to ignore certain endpoints or middlewares.
Timed-out requests will cause this middleware to return with a “408 Request Timeout” response.
Badly-written C extensions may not be timed out. Audit and fix (or remove) those extensions before relying on this module.
Do NOT, under any circumstances nest and load this in the same middleware stack. You may load this in parallel in the same process completely independent middleware stacks, but DO NOT load this twice so it nests. Things will break!
This will behave badly if system time is changed since Ruby does not expose a monotonic clock for users, so don't change the system time while this is running. All servers should be running ntpd anyways.
“ensure” clauses may not fire properly or be interrupted during execution, so do not mix this module with code which relies on “ensure”. (This is also true for the “Timeout” module in the Ruby standard library)
“recursive locking” ThreadError exceptions may occur if ThreadTimeout fires while a Mutex is locked (because “ensure” clauses may not fire properly).