When I tried executing code similar to the example in the README.md, i.e.:
require 'ruby_ami'
def handle_event(event, stream)
case event.name
when 'FullyBooted'
puts "The connection was successful. Originating a call."
response = stream.send_action 'QueueStatus', 'Queue' => queue
puts "The call origination resulted in #{response.inspect}"
end
end
stream = RubyAMI::Stream.new '127.0.0.1', 5038, 'manager', 'password',
->(e, stream) { handle_event e, stream },
Logger.new(STDOUT), 10
Celluloid::Actor.join(stream)It seems to deadlock during the send_action call. My hunch is that this example given was originally written for when ruby_ami was using EventMachine instead of Celluloid. I suspect it deadlocks because when send_action is called inside handle_event, the connection.wait that's gets called blocks the thread (or actor or whatever it's called) that should be reading the socket. Hence it's waiting for a response it can't get, it deadlocks.
I was able to fix it by moving the stream.send_action outside of handle_event and put a sleep before it to make sure AMI was fully booted. But I wanted to find out if my theory was correct, and if we should update the README.md with a working example. (If that's the case I can submit a PR)
When I tried executing code similar to the example in the README.md, i.e.:
It seems to deadlock during the
send_actioncall. My hunch is that this example given was originally written for when ruby_ami was using EventMachine instead of Celluloid. I suspect it deadlocks because whensend_actionis called insidehandle_event, theconnection.waitthat's gets called blocks the thread (or actor or whatever it's called) that should be reading the socket. Hence it's waiting for a response it can't get, it deadlocks.I was able to fix it by moving the stream.send_action outside of
handle_eventand put a sleep before it to make sure AMI was fully booted. But I wanted to find out if my theory was correct, and if we should update the README.md with a working example. (If that's the case I can submit a PR)