RubyFS stops listening after sending an event

[bklang]

I have code that looks like this to respond to MESSAGE_QUERY events from FreeSWITCH and respond by providing Message Waiting Indicator messages:

def self.handle_event(event)
      return unless event.is_a? RubyFS::Event
      case event.event_name
      when "MESSAGE_QUERY"
        begin
          logger.debug "Received message query for #{event.content[:message_account]}"
          mailbox_id, account_id = parse_address event.content[:message_account]
          messages = WebApiClient.get_messages(account_id, mailbox_id) || EMPTY_MAILBOX

          report mailbox_id, account_id, messages
        rescue InvalidMailboxAddress
          logger.error "Received MAILBOX_QUERY for an unrecognized mailbox: #{event.content[:message_account]}"
        end
      end
    end

The first MESSAGE_QUERY received by Adhearsion is properly handled. You can see this in the packet capture here: https://gist.github.com/bklang/37d3b19f430af099718c#file-gistfile1-txt-L27

Lines 27-30 are Adhearsion talking to FreeSWITCH; every other line in that file is FreeSWITCH talking to Adhearsion.

The Adhearsion TRACE logs properly show all IES messages being received up to the point of sending the sendevent message. After that point, no further messages are logged, and the subsequent MESSAGE_QUERY events are ignored.

[benlangfeld]

Here #report does RubyFS::Stream#command "sendevent message_waiting", {...}.

[benlangfeld]

@bklang A couple of things I'd like you to try:

fs.command "sendevent message_waiting", options do |response|
# throw away
end

fs.async.command "sendevent message_waiting", options

If either (or both) of these "fix" the issue that will help me narrow down what I'm looking at.

[bklang]

I will try both of these. But to make sure I understand the impact of each:

The first, passing a callback, if it "works" likely represents a memory leak, as every sent command will register a block that will never be called?

The second, calling it async, will eventually deadlock Celluloid as soon as the thread pool is tied up with all the async commands?

I'll let you know the results of my testing.

[benlangfeld]

The first, passing a callback, if it "works" likely represents a memory leak, as every sent command will register a block that will never be called?

Why would it not be called? My expectation is that it would be called and there would be no leak.

The second, calling it async, will eventually deadlock Celluloid as soon as the thread pool is tied up with all the async commands?

Again, I don't see why this would be the case.

[bklang]

Both solutions work:

When passing a callback, I am able to get multiple commands to execute, in other words, no deadlock. Also, the callback is invoked, as logging inside the block is observed.

When using .async, I am also able to get multiple commands to execute.

[benlangfeld]

@bklang Try your original code again with that change?

[bklang]

From Gemfile.lock:

GIT
  remote: git://github.com/adhearsion/ruby_fs.git
  revision: 2f9808e2ab31088a441b5bbc559d505a3aec038a
  branch: bugfix/6-event-delivery-failure
  specs:
    ruby_fs (1.1.1)
      celluloid-io (~> 0.13)

No such luck. Still seems to hang after the first call to #command