I''m not sure how best to describe what''s happening, so
here''s the EM runner
code:
class ServerRunner
def self.start
@@device_manager = DeviceManager.new
EM::run {
EM::start_server "localhost", server_port, DeviceConnection do
|c|
c.device_manager = @@device_manager
end
EM::start_server "localhost", api_port, APIConnection do |c|
c.device_manager = @@device_manager
end
}
end
def self.stop
EM::stop
end
end
As you can see, I"m starting up two TCP servers here. They run fine, act as
they should, but in my tests I want to bring the servers down and up for
each test (cleaning out state and what not). So I call ::start in setup()
and ::stop in teardown().
However, EM::stop is causing the following crash:
terminate called after throwing an instance of
''std::runtime_error''
what(): not initialized
I''ve tried explicitly shutting down the servers by their signatures,
but
that gives me the same error. Have I missed something about EM dealing with
proper cleanup or is this a valid bug?
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071105/30bebbf7/attachment.html
Small update: It seems that when there''s a Ruby exception thrown (missing method, undefined Constant, etc), this error gets thrown. It doesn''t seem to be an issue with EM::stop like I initially thought. This happens with both EM 0.8.1 and 0.9.0 (linux). However, it doesn''t happen with a basic test script, just during the processing of receive_data from the looks of it. Jason On 11/5/07, Jason Roelofs <jameskilton at gmail.com> wrote:> > I''m not sure how best to describe what''s happening, so here''s the EM > runner code: > > class ServerRunner > def self.start > @@device_manager = DeviceManager.new > > EM::run { > EM::start_server "localhost", server_port, DeviceConnection do |c| > c.device_manager = @@device_manager > end > > EM::start_server "localhost", api_port, APIConnection do |c| > c.device_manager = @@device_manager > end > } > end > > def self.stop > EM::stop > end > end > > As you can see, I"m starting up two TCP servers here. They run fine, act > as they should, but in my tests I want to bring the servers down and up for > each test (cleaning out state and what not). So I call ::start in setup() > and ::stop in teardown(). > > However, EM::stop is causing the following crash: > > terminate called after throwing an instance of ''std::runtime_error'' > what(): not initialized > > I''ve tried explicitly shutting down the servers by their signatures, but > that gives me the same error. Have I missed something about EM dealing with > proper cleanup or is this a valid bug? > > Jason > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071105/303b5091/attachment-0001.html
On 11/5/07, Jason Roelofs <jameskilton at gmail.com> wrote:> > Small update: > > It seems that when there''s a Ruby exception thrown (missing method, > undefined Constant, etc), this error gets thrown. It doesn''t seem to be an > issue with EM::stop like I initially thought. > > This happens with both EM 0.8.1 and 0.9.0 (linux). However, it doesn''t > happen with a basic test script, just during the processing of receive_data > from the looks of it. > > JasonI was just going to ask if a Ruby exception is getting thrown. I''ve seen that often in constructing test cases for EM, which is often a serious pain. As a rule, you want to catch Ruby exceptions if you can. That should solve your problem here. Also, if you sync to the head revision, there''s a new mechanism which allows you to specify an application-wide exception handling hook. It''s a problem that EM test cases interact badly with Ruby exceptions. We ought to solve it by developing standard patterns for writing EM-based tests. If you still have trouble, can you post a more complete example? There are some use cases in EM''s own test suite that may help you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071105/a6d27f1c/attachment.html
On 11/5/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > On 11/5/07, Jason Roelofs <jameskilton at gmail.com> wrote: > > > > Small update: > > > > It seems that when there''s a Ruby exception thrown (missing method, > > undefined Constant, etc), this error gets thrown. It doesn''t seem to be an > > issue with EM::stop like I initially thought. > > > > This happens with both EM 0.8.1 and 0.9.0 (linux). However, it doesn''t > > happen with a basic test script, just during the processing of receive_data > > from the looks of it. > > > > Jason > > > > I was just going to ask if a Ruby exception is getting thrown. I''ve seen > that often in constructing test cases for EM, which is often a serious pain. > As a rule, you want to catch Ruby exceptions if you can. That should solve > your problem here. Also, if you sync to the head revision, there''s a new > mechanism which allows you to specify an application-wide exception handling > hook. > > It''s a problem that EM test cases interact badly with Ruby exceptions. We > ought to solve it by developing standard patterns for writing EM-based > tests. If you still have trouble, can you post a more complete example? > There are some use cases in EM''s own test suite that may help you. >This is getting really frustrating now. I''m running into this problem more and more. I''ll try to get a simple test case in place, but for now do you know of any quick hack to propogate Ruby exceptions all the way through? Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071105/89e6ce98/attachment.html
On 11/5/07, Jason Roelofs <jameskilton at gmail.com> wrote:> > This is getting really frustrating now. I''m running into this problem > more and more. I''ll try to get a simple test case in place, but for now do > you know of any quick hack to propogate Ruby exceptions all the way through? > > > Jason >Try the head revision. I just wrote a quick test runner with two tests. both of which throw a Ruby RuntimeError. There''s no problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071105/72604f39/attachment.html
> As you can see, I"m starting up two TCP servers here. They run fine, act > as they should, but in my tests I want to bring the servers down and upfor> each test (cleaning out state and what not). So I call ::start in setup() > and ::stop in teardown().Try to catch your exception and then run begin rescue => e puts e.backtrace.inspect end or what not -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071105/c799396b/attachment.html
On 11/5/07, Jason Roelofs <jameskilton at gmail.com> wrote:> > > This is getting really frustrating now. I''m running into this problem more > and more. I''ll try to get a simple test case in place, but for now do you > know of any quick hack to propogate Ruby exceptions all the way through? >Another alternative: Rather than calling EM.stop in your teardown method, do this: EM.stop if EM.reactor_running? This will work in release 0.9.0. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071105/7d4d29b0/attachment.html
On 11/5/07, Jason Roelofs <jameskilton at gmail.com> wrote:> > This is getting really frustrating now. I''m running into this problem > more and more. I''ll try to get a simple test case in place, but for now do > you know of any quick hack to propogate Ruby exceptions all the way through? > > > Jason >Jason, any resolution of this issue? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071106/fe40462c/attachment.html
On 11/6/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:> > On 11/5/07, Jason Roelofs <jameskilton at gmail.com> wrote: > > > > This is getting really frustrating now. I''m running into this problem > > more and more. I''ll try to get a simple test case in place, but for now do > > you know of any quick hack to propogate Ruby exceptions all the way through? > > > > > > Jason > > > > > Jason, any resolution of this issue? >I still don''t know why this is happening, but I''ve finally found out where. It works when I do the EM.reactor_running?. Here''s a test case to show the proper exception throwing case, and one that shows the error throwing case: $:.unshift "../lib" require ''eventmachine'' class TestStdErrorProblem < Test::Unit::TestCase Localhost = "127.0.0.1" Localport = 9801 class TestConnection < EM::Connection def post_init end def receive_data(data) if data =~ /This breaks/ do_something_undefined end end def unbind end end # This guy properly propogates Ruby errors and exceptions class ManagerGood def self.start EM::run { EM::start_server Localhost, Localport, TestConnection } end def self.stop EM::stop if EM::reactor_running? end end # This guy throws std::runtime_error, completely hiding all # Ruby errors and exceptions class ManagerBad def self.start EM::run { EM::start_server Localhost, Localport, TestConnection } end def self.stop EM::stop end end def connect_to_server(options = {}) options[:host] ||= Localhost options[:port] ||= Localport s = TCPSocket.new(options[:host], options[:port]) yield s end # Set this to test_, see that no method found exception gets thrown def this_throws_an_exception_as_expected thread = Thread.new do ManagerGood.start end connect_to_server do |connection| connection.puts("This breaks\n") end ManagerGood.stop thread.join end # Set this to test_, see that stuff dies miserably def this_throws_std_runtime_error thread = Thread.new do ManagerBad.start end connect_to_server do |connection| connection.puts("This breaks\n") end ManagerBad.stop thread.join end end So the answer for me is "if EM::reactor_running?", but I''m sure someone else will run into this. Maybe EM::stop needs to do some extra checking internally? Thanks for your help, hopefully you can fix this problem. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071106/dd157575/attachment-0001.html
On 11/6/07, Jason Roelofs <jameskilton at gmail.com> wrote:> > > > So the answer for me is "if EM::reactor_running?", but I''m sure someone > else will run into this. Maybe EM::stop needs to do some extra checking > internally? >I was thinking of making EM::stop a no-op in case the reactor is already stopped. I haven''t been able to think of any regressions that this would cause. Anyone? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/eventmachine-talk/attachments/20071106/fa2868cc/attachment.html