rails 2 and slow external services

ghazel at gmail.com ghazel at gmail.com
Tue Dec 14 03:03:12 EST 2010

On Mon, Dec 13, 2010 at 11:49 PM, Eric Wong <normalperson at yhbt.net> wrote:
> ghazel at gmail.com wrote:
>> I'm not sure how I would know that - I'm not actually sure which
>> timeout you mean. "timeout" in the config/unicorn.rb and
>> config/rainbows.rb is 300, same as proxy_read_timeout. Is that it? Are
>> you saying when that is hit that Rainbows! and Unicorn act
>> differently?
> Yes, the purpose of the "timeout" in the Unicorn config has always been
> to kill unrecoverably stuck processes, Rainbows! just enforces that
> more strictly.
> The simple nature of Unicorn allows lazy people can use it to avoid
> adding timeouts to their code without causing harm to other clients.
> Since Rainbows! is designed to serve multiple clients in the same
> process, killing a process would break all the clients on the process,
> not just the one client that triggered the timeout.  So using Rainbows!
> requires more discipline from the application authors than Unicorn.

Hm. Well I was unaware that there was any timeout issue with my
application. When a Unicorn process timed out and died, how did the
request not timeout with nginx? Was it re-submitted to another worker?


More information about the rainbows-talk mailing list