DEPLOY FAQ HACKING LICENSE NEWS README SIGNALS Sandbox Static_Files Summary TUNING Test_Suite rainbows_1 vs_Unicorn
Rainbows ActorSpawn AppPool Base Configurator Coolio CoolioThreadPool CoolioThreadSpawn DevFdResponse Epoll EventMachine FiberPool FiberSpawn MaxBody NeverBlock Rev RevFiberSpawn RevThreadPool RevThreadSpawn Revactor Sendfile ServerToken StreamResponseEpoll ThreadPool ThreadSpawn ThreadTimeout WriterThreadPool WriterThreadSpawn XEpoll XEpollThreadPool XEpollThreadSpawn

class Rainbows::ThreadTimeout

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 (, the following line will cause execution to timeout in 1.5 seconds.

use Rainbows::ThreadTimeout, :timeout => 1.5

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

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).

Pages Classes Methods
mail archives:
source code: git clone
	torsocks git clone http://ou63pmih66umazou.onion/rainbows.git