if the controller action has not yet streamed any data, actions should
process as normal, and errors should trigger the appropriate behavior
(500, or in the case of ActionController::BadRequest, a 400 Bad Request)
Without timeout:
this test executed infinitely on JRuby
Passes on MRI
With Timeout:
this test gracefully fails on JRuby
Passes on MRI, tested on v2.0 & v1.9.3
Any exceptions that occured at the view or controller level for a
controller using ActionController::Live would cause the server to either
hang with an open socket indefinitely, or immediately crash (depending
on whether the server was launched with rails s or directly). Changed
the behavior of exceptions to act the same as streaming templates for
html requests, and allow for an on_error callback if needed.
responses.
Processing controller actions in a separate thread allows us to work
around the rack api - we can allow the user to set status and headers,
then block until the first bytes are written. As soon as the first
bytes are written, the main thread can return the status, headers, and
(essentially) a queue for the body.
