kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity
rails--rails/actionpack/test/controller/live_stream_test.rb

211 lines
5.6 KiB
Ruby
Raw Normal View History

added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
require 'abstract_unit'
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
require 'active_support/concurrency/latch'
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
module ActionController
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
class LiveStreamTest < ActionController::TestCase
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
class TestController < ActionController::Base
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
include ActionController::Live
attr_accessor :latch, :tc
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
def self.controller_path
'test'
end
close the response when the response body is set so that normal render calls will work
2012-07-29 23:33:16 -04:00
def render_text
render :text => 'zomg'
end
header hash is duped before being sent up the rack stack
2012-07-29 23:26:40 -04:00
def default_header
response.stream.write "<html><body>hi</body></html>"
response.stream.close
end
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
def basic_stream
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
response.headers['Content-Type'] = 'text/event-stream'
%w{ hello world }.each do |word|
response.stream.write word
end
response.stream.close
end
def blocking_stream
response.headers['Content-Type'] = 'text/event-stream'
%w{ hello world }.each do |word|
response.stream.write word
latch.await
end
response.stream.close
end
def thread_locals
tc.assert_equal 'aaron', Thread.current[:setting]
Alias refute methods to assert_not and perfer assert_not on tests
2012-12-28 18:49:41 -05:00
tc.assert_not_equal Thread.current.object_id, Thread.current[:originating_thread]
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
response.headers['Content-Type'] = 'text/event-stream'
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
%w{ hello world }.each do |word|
response.stream.write word
end
response.stream.close
end
Handle conditional get in live requests - this will prevent error when using stale on live streams(issue #9636)
2013-03-14 04:13:10 -04:00
def with_stale
render :text => 'stale' if stale?(:etag => "123")
end
Exception handling for controllers using ActionController::Live 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.
2013-03-07 17:49:03 -05:00
def exception_in_view
render 'doesntexist'
end
def exception_with_callback
response.headers['Content-Type'] = 'text/event-stream'
response.stream.on_error do
response.stream.write %(data: "500 Internal Server Error"\n\n)
response.stream.close
end
raise 'An exception occurred...'
end
def exception_in_exception_callback
response.headers['Content-Type'] = 'text/event-stream'
response.stream.on_error do
raise 'We need to go deeper.'
end
response.stream.write params[:widget][:didnt_check_for_nil]
end
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
end
tests TestController
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
class TestResponse < Live::Response
def recycle!
initialize
end
end
def build_response
TestResponse.new
end
Exception handling for controllers using ActionController::Live 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.
2013-03-07 17:49:03 -05:00
def assert_stream_closed
assert response.stream.closed?, 'stream should be closed'
end
def capture_log_output
output = StringIO.new
old_logger, ActionController::Base.logger = ActionController::Base.logger, ActiveSupport::Logger.new(output)
begin
yield output
ensure
ActionController::Base.logger = old_logger
end
end
make sure set_response! sets the correct response object
2012-07-29 22:46:36 -04:00
def test_set_response!
@controller.set_response!(@request)
assert_kind_of(Live::Response, @controller.response)
assert_equal @request, @controller.response.request
end
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
def test_write_to_stream
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
@controller = TestController.new
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
get :basic_stream
Controller actions are processed in a separate thread for live 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.
2012-07-29 22:23:19 -04:00
assert_equal "helloworld", @response.body
assert_equal 'text/event-stream', @response.headers['Content-Type']
end
def test_async_stream
@controller.latch = ActiveSupport::Concurrency::Latch.new
parts = ['hello', 'world']
@controller.request = @request
@controller.response = @response
t = Thread.new(@response) { |resp|
resp.stream.each do |part|
assert_equal parts.shift, part
ol = @controller.latch
@controller.latch = ActiveSupport::Concurrency::Latch.new
ol.release
end
}
@controller.process :blocking_stream
assert t.join
end
def test_thread_locals_get_copied
@controller.tc = self
Thread.current[:originating_thread] = Thread.current.object_id
Thread.current[:setting] = 'aaron'
get :thread_locals
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
end
header hash is duped before being sent up the rack stack
2012-07-29 23:26:40 -04:00
def test_live_stream_default_header
@controller.request = @request
@controller.response = @response
@controller.process :default_header
_, headers, _ = @response.prepare!
assert headers['Content-Type']
end
close the response when the response body is set so that normal render calls will work
2012-07-29 23:33:16 -04:00
def test_render_text
get :render_text
make sure the body finishes rendering before checking response closure
2012-08-02 18:04:36 -04:00
assert_equal 'zomg', response.body
Exception handling for controllers using ActionController::Live 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.
2013-03-07 17:49:03 -05:00
assert_stream_closed
end
def test_exception_handling_html
capture_log_output do |output|
get :exception_in_view
assert_match %r((window\.location = "/500\.html"</script></html>)$), response.body
assert_match 'Missing template test/doesntexist', output.rewind && output.read
assert_stream_closed
end
end
def test_exception_handling_plain_text
capture_log_output do |output|
get :exception_in_view, format: :json
assert_equal '', response.body
assert_match 'Missing template test/doesntexist', output.rewind && output.read
assert_stream_closed
end
end
def test_exception_callback
capture_log_output do |output|
get :exception_with_callback, format: 'text/event-stream'
assert_equal %(data: "500 Internal Server Error"\n\n), response.body
assert_match 'An exception occurred...', output.rewind && output.read
assert_stream_closed
end
end
def test_exceptions_raised_handling_exceptions
capture_log_output do |output|
get :exception_in_exception_callback, format: 'text/event-stream'
assert_equal '', response.body
assert_match 'We need to go deeper', output.rewind && output.read
assert_stream_closed
end
close the response when the response body is set so that normal render calls will work
2012-07-29 23:33:16 -04:00
end
Handle conditional get in live requests - this will prevent error when using stale on live streams(issue #9636)
2013-03-14 04:13:10 -04:00
def test_stale_without_etag
get :with_stale
assert_equal 200, @response.status.to_i
end
def test_stale_with_etag
@request.if_none_match = Digest::MD5.hexdigest("123")
get :with_stale
assert_equal 304, @response.status.to_i
end
added live responses which can be written and read in separate threads
2012-07-29 20:26:07 -04:00
end
end
Copy permalink